feat(timeline_detach_ancestor): success idempotency #8354
Merged
+633
−75
Conversation
This file contains 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
3139 tests run: 3018 passed, 0 failed, 121 skipped (full report)Code coverage* (full report)
* collected from Rust tests only The comment gets automatically updated with the latest test results
a3533f4 at 2024-07-15T17:55:16.606Z :recycle: |
The flakyness was added first in the previous PR but only fixed on this one, so hopefully I can merge these quite soon to each other. |
koivunej
force-pushed
the
joonas/idempotent_tad
branch
from
6cd67e8
to
ccce350
Compare
VladLazar
reviewed
Jul 12, 2024
VladLazar
reviewed
Jul 12, 2024
VladLazar
approved these changes
Jul 12, 2024
koivunej
force-pushed
the
joonas/idempotent_tad
branch
from
5efd16d
to
40d63be
Compare
basically just a newtype around the mutexguard for accessing the latest uploaded index part.
now historically detached timelines will on retry return 200 OK, with stable ordered reparented timelines. these timelines will be subject to future changes (like timeline archival, or having deleted some timelines).
unsure why we report those in text; is it difficult to show the status code in python?
this works around flakyness noticed in [report] while also keeping it warning **not allowed** for the expected successes. [report]: https://neon-github-public-dev.s3.amazonaws.com/reports/pr-8354/9891172764/index.html#suites/a1c2be32556270764423c495fad75d47/af1143a64a197a49
to observe the 503
unsure if we can really cancel timelinewriter with std-fs...
obviously this does not check for every case, but still, should be good enough.
it might be that we should just retry this automatically.
koivunej
force-pushed
the
joonas/idempotent_tad
branch
from
5bb9be8
to
a3533f4
Compare
problame
pushed a commit
that referenced
this pull request
Jul 22, 2024
Right now timeline detach ancestor reports an error (409, "no ancestor") on a new attempt after successful completion. This makes it troublesome for storage controller retries. Fix it to respond with `200 OK` as if the operation had just completed quickly. Additionally, the returned timeline identifiers in the 200 OK response are now ordered so that responses between different nodes for error comparison are done by the storage controller added in #8353. Design-wise, this PR introduces a new strategy for accessing the latest uploaded IndexPart: `RemoteTimelineClient::initialized_upload_queue(&self) -> Result<UploadQueueAccessor<'_>, NotInitialized>`. It should be a more scalable way to query the latest uploaded `IndexPart` than to add a query method for each question directly on `RemoteTimelineClient`. GC blocking will need to be introduced to make the operation fully idempotent. However, it is idempotent for the cases demonstrated by tests. Cc: #6994
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.
Right now timeline detach ancestor reports an error (409, "no ancestor") on a new attempt after successful completion. This makes it troublesome for storage controller retries. Fix it to respond with
200 OKas if the operation had just completed quickly.Additionally, the returned timeline identifiers in the 200 OK response are now ordered so that responses between different nodes for error comparison are done by the storage controller added in #8353.
Design-wise, this PR introduces a new strategy for accessing the latest uploaded IndexPart:
RemoteTimelineClient::initialized_upload_queue(&self) -> Result<UploadQueueAccessor<'_>, NotInitialized>. It should be a more scalable way to query the latest uploadedIndexPartthan to add a query method for each question directly onRemoteTimelineClient.GC blocking will need to be introduced to make the operation fully idempotent. However, it is idempotent for the cases demonstrated by tests.
Cc: #6994