Repository navigation
Say which data update error row covers a download cut short - #145
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #144
The problem
The Errors section of the data updates feature has two rows for a request for new data that fails, and neither says which one covers a download that starts and is then cut short, for example when the connection is closed part way through the file. #144 sets this out. Read on its own, the first row's description, "Connecting to the data update URL failed", points a download cut short at the second row, "The data update URL gave no response", and the languages split between the two.
What the specification says
pipeline-specification/features/data-updates.mdlines 481 to 483 at 88b8c0a:So .NET decides the row.
DataUpdateService.cslines 1305 to 1326 at 8b3220b sends the request withSendAsyncinside atry, and itscatchthrows the first row's message. That form ofSendAsync"will complete once the entire response including content is read", in Microsoft's documentation, so a body cut short fails inside it and takes the first row. .NET writes the second row's message only whenSendAsyncreturns no response at all.What changed
Two descriptions in the Errors table, as #144 suggests, and nothing else. The levels, statuses and messages are unchanged.
What it means for each language
Python already reports a download cut short under the first row, as #144 shows. .NET does by definition. Node.js wrote the second row's message until 51degrees-node#94. Java, Go and Rust report it in a way that matches neither row, and each has its own issue: 51degrees-java#125, 51degrees-go#123 and 51degrees-rust#403. This change settles what each of them should give.
Checks
Documentation only, so there is no build. On the head, 3c61752, UTM link lint and Only rc into main passed. The file keeps LF line endings in the repository, as on
rc, and the table keeps its column widths.