-
Notifications
You must be signed in to change notification settings - Fork 1
feat(llc)!: adopt the stream_core error layer and upload task API #126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
e6ac4e4
745f248
d4c870e
a02c45e
39c109b
e5f858e
0619681
13a4e25
3182f08
c4414b9
20d6b6f
e382757
309fe20
b79c29a
240d425
3f787f9
60f0caf
0e44773
d77277c
89b5f9a
4f9821f
26e0388
c526e98
35a9027
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -77,25 +77,15 @@ class CapabilitiesRepository { | |
| } | ||
|
|
||
| extension on Result<Map<String, List<FeedOwnCapability>>> { | ||
| bool shouldRetry() { | ||
| switch (this) { | ||
| case api.Success(): | ||
| return false; | ||
|
|
||
| case final api.Failure failure: | ||
| final error = failure.error; | ||
| if (error is! StreamDioException) { | ||
| return false; | ||
| } | ||
| final exception = error.exception; | ||
| if (exception is! HttpClientException) { | ||
| return false; | ||
| } | ||
| final statusCode = exception.statusCode; | ||
| if (statusCode == null) { | ||
| return false; | ||
| } | ||
| return statusCode < 100 || statusCode >= 500; | ||
| } | ||
| } | ||
| bool shouldRetry() => switch (this) { | ||
| api.Success() => false, | ||
| api.Failure(:final error) => switch (error) { | ||
| StreamNetworkException(isCancelled: true) => false, | ||
| StreamNetworkException() => true, | ||
| // A rate limit is not retried here: this waits a fixed moment, which is | ||
| // not the wait a rate limit asks for. | ||
| StreamApiException(:final statusCode) => statusCode < 100 || statusCode >= 500, | ||
| _ => false, | ||
|
Comment on lines
+83
to
+88
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The rewrite added two decisions that weren't here before — a cancelled network error doesn't retry, and neither does a 4xx — and only the "network error does retry" case got a test. Both are cheap to pin down, and the cancelled one especially: if that branch ever regressed, the retry would fire against a request that was deliberately called off during dispose, and nothing would notice.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Tried to pin both and could not, so here is what I found rather than a promise. Proving a negative here means showing a second call never happens, and the call it must not make is scheduled behind two nested waits: So I spiked time control. One real bug fell out: The gap stands, and the follow-up now has a concrete scope: make the batcher and the backoff observable under fake time, then both branches become one-line assertions.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Correcting my earlier reply on this thread — I was wrong twice.
And the reason nothing was retrying was a bug, not the test. Fixed in 26e0388 with six tests, and 4f9821f moves The eight retry-branch tests are not in this PR. Getting them to the state surface needs a |
||
| }, | ||
| }; | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -186,6 +186,16 @@ class Feed with Disposable { | |
| /// | ||
| /// The [request] contains the activity data to add. | ||
| /// | ||
| /// Attachments in [FeedAddActivityRequest.attachmentUploads] are uploaded | ||
| /// first, and the activity is added once they are all in. To follow those | ||
| /// uploads or call them off, upload through | ||
| /// `StreamFeedsClient.attachmentUploader` instead and pass the results as | ||
| /// [FeedAddActivityRequest.attachments]. | ||
| /// | ||
| /// Throws an [ArgumentError] if two of those attachments share an id. Ids | ||
| /// default to a fresh UUID, so this only happens when one is given | ||
| /// explicitly, or the same attachment is listed twice. | ||
|
Comment on lines
+195
to
+197
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This throw is documented on
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Added in 89b5f9a: |
||
| /// | ||
| /// Returns a [Result] containing the added [ActivityData] if successful, or an error if the | ||
| /// operation fails. | ||
| Future<Result<ActivityData>> addActivity({ | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the line is being touched anyway:
previousError?.isTokenExpired == truereads better than?? falsefor a nullable bool, and it's what the rest of the codebase leans towards.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left as
?? falsefor now — you and CodeRabbit both landed on this line, and it is the one place I would rather not touch twice in one review. Happy to take it in a follow-up sweep if the codebase is standardising on== true.