This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
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.
Stabilize support for MSC3970: updated transaction semantics (scope to
device_id
) #15629Stabilize support for MSC3970: updated transaction semantics (scope to
device_id
) #15629Changes from 5 commits
be63aff
68ce9ad
e095d92
a34fbf3
3acc1b3
283d3c5
d55a74b
2117baa
e0a72c0
06d46e3
cceef14
6c4e335
a67561b
bb08790
9377889
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Is there a target version of
SCHEMA_COMPAT_VERSION
you need? If you can find out, might be worth writing it here.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.
Errr, so right now we write to both
event_txn_id
andevent_txn_id_device_id
. I think we want to leave this as-is so we can rollback if needed.I guess in the future we would want to:
event_txn_id
and bump theSCHEMA_VERSION
SCHEMA_COMPAT_VERSION
, rip out the codeDoes that sound like the right series of steps?
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.
We talked about this a bit: https://matrix.to/#/!vcyiEtMVHIhWXcJAfl:sw1v.org/$WQwonqO7etYpa0ik4aVzVsf32R_VOqIyPzBjTl3pjps?via=matrix.org&via=element.io&via=beeper.com
My tl;dr is that the above steps look reasonable, although you usually want to stop reading before writing. Unfortunately we do still use this for certain situations, e.g. appservice users don't have device IDs. So we would need to figure out what to do there?
My inclination is to merge this as-is (so as to not block Matrix 1.7 support) and file a follow-up.
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.
Probably good to add a comment to the diff on the caveat for why the access token fallback needs to stay until that is figured out
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.
Yeah, I was planning to point to an issue. Was waiting to see if others had thoughts before clicking merge.
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.
Taking a step back and re-evaluating my other threads with @sandhose (and re-reading the comments in this PR) I don't actually think we can remove this since it gets used for guests, appservice users, and access tokens from the admin API. 😢
I've made two changes:
Could folks (in particular @sandhose) let me know if these still read OK? I feel like I'm missing something, but I've tried to include my current understanding in the comments.
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.
The thing is, guests and appservice users don't have access token IDs anyway, so it basically won't do anything if we keep it. The only thing left is admin-minted, device-less tokens.
Keep in mind, there are two layers of things that ensure idempotency:
Also, this is only for idempotency, the transaction ID echo in event serialisation is handled by the event internal metadata JSON blob, which is separate from those tables.
If I'm not mistaken, I think this would only affect
I don't mind keeping this, but also I don't think it's worth keeping it around.
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.
And I suppose the same rules apply to the event internal metadata info -- guests and appservices users don't have access token IDs so we can't be storing it there anyway.
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.
Thinking through this a bit more I think we need two separate approaches:
Database transaction mapping
This describes what to do with "the db-persisted (for 24h) transaction_id -> event_id mapping".
This only survives for 24 hours, but that's not really relevant to the conversation of rolling back (or forwards). As background, there's two tables (
event_txn_id
andevent_txn_id_device_id
) for access token IDs and device IDs, respectively. To gracefully handle up/downgrades I propose:event_txn_id_device_id
, fallback toevent_txn_id
). Bump the schema version to V.event_txn_id
, bump the schema version to V+1.At this point we have a database schema still compatible with today, but we're not using data
event_txn_id
, so rolling back to e.g. N is fine, but not before N. To enforce this, bump the minimum schema version to V.event_txn_id
table.At this point we no longer have a database schema compatible with N, but we can still rollback OK to N+2. So bump the minimum schema version to V+1.
Internal metadata
The device ID & access token ID are unconditionally written into the internal metadata of events. It then follows similar logic where the transaction ID is returned to a user when serializing the event if:
A similar thing should be followed:
This implies that we would leave the logic for the fallback "forever", but I think we're already at am minimum schema version where we've always written both values, so we only need to be concerned with old data.
An option here would be to do a data migration for any event who has a token ID which still exists in the database, add the device ID. Then remove the fallback code. This seems a bit onerous though.
Footnotes
Device IDs matching should also be gated by the user ID, I think. There's more risk of those overlapping that the token IDs since they're client controllable. ↩
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.
#16042 was filed to handle follow-up.