Skip to content

Fix badges and CI - #3

Merged
fathyb merged 6 commits into
masterfrom
fix/badges
Oct 13, 2018
Merged

Fix badges and CI#3
fathyb merged 6 commits into
masterfrom
fix/badges

Conversation

@fathyb

Copy link
Copy Markdown
Contributor

No description provided.

@fathyb
fathyb merged commit 9ab58a0 into masterOct 13, 2018
@fathyb
fathyb deleted the fix/badges branch October 13, 2018 18:58
abueide added a commit that referenced this pull request Mar 6, 2026
Adds error classification system to support TAPI backoff v2. This enables
intelligent decisions about which errors are retryable vs permanent.
Changes:
- classifyError(): Classifies HTTP errors with configurable behavior
- Supports statusCodeOverrides for per-code behavior
- default4xxBehavior and default5xxBehavior for fallback handling
- Special handling for 429 rate limiting
- parseRetryAfter(): Parses Retry-After header (seconds or HTTP date)
- HTTP config defaults with sensible retry behaviors
Error classification returns:
- isRetryable: Whether error should be retried
- errorType: 'rate_limit' | 'transient' | 'permanent'
- retryAfterSeconds: Optional delay from Retry-After header
This builds on the infrastructure from PR #1 and will be integrated
into the upload flow in PR #3.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
abueide added a commit that referenced this pull request Mar 6, 2026
Adds error classification system to support TAPI backoff v2. This enables
intelligent decisions about which errors are retryable vs permanent.
Changes:
- classifyError(): Classifies HTTP errors with configurable behavior
- Supports statusCodeOverrides for per-code behavior
- default4xxBehavior and default5xxBehavior for fallback handling
- Special handling for 429 rate limiting
- parseRetryAfter(): Parses Retry-After header (seconds or HTTP date)
- HTTP config defaults with sensible retry behaviors
Error classification returns:
- isRetryable: Whether error should be retried
- errorType: 'rate_limit' | 'transient' | 'permanent'
- retryAfterSeconds: Optional delay from Retry-After header
This builds on the infrastructure from PR #1 and will be integrated
into the upload flow in PR #3.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
abueide added a commit that referenced this pull request Mar 9, 2026
…ggregation
Parallel batch processing (PR #3):
- Upload batches in parallel with Promise.all() for performance
- Collect structured BatchResult for each batch
- Aggregate errors by type (success, 429, transient, permanent)
- Extract messageIds from each batch
State machine integration (PR #4):
- Check canUpload() and canRetry() gates before sending
- Handle 429 ONCE per flush with longest retry-after
- Handle transient errors ONCE per flush
- Dequeue events by messageId (success + permanent)
- Reset state machines on success
- Comprehensive logging
Key design decisions:
- Single retry increment per flush (not per batch)
- Longest 429 wins (most conservative)
- MessageId-based dequeue (stable across re-chunking)
- Parallel processing preserved (performance)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
abueide added a commit that referenced this pull request Mar 9, 2026
…ggregation
Parallel batch processing (PR #3):
- Upload batches in parallel with Promise.all() for performance
- Collect structured BatchResult for each batch
- Aggregate errors by type (success, 429, transient, permanent)
- Extract messageIds from each batch
State machine integration (PR #4):
- Check canUpload() and canRetry() gates before sending
- Handle 429 ONCE per flush with longest retry-after
- Handle transient errors ONCE per flush
- Dequeue events by messageId (success + permanent)
- Reset state machines on success
- Comprehensive logging
Key design decisions:
- Single retry increment per flush (not per batch)
- Longest 429 wins (most conservative)
- MessageId-based dequeue (stable across re-chunking)
- Parallel processing preserved (performance)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@fathyb