TagResource, UntagResource and ListTagsOfResource during a table's DELETING window answer differently from DynamoDB
维护者通常 2 天内回复
评估
这个 Issue 还没有评估数据。
描述
Summary
During a table's DELETING window the service refuses TagResource and UntagResource and serves ListTagsOfResource; ExtendDB answers differently on every backend.
Request during DELETING |
Service (measured 2026-10-25, us-east-1) | ExtendDB main 744ea291 |
ExtendDB after #550 (PostgreSQL, SQLite) |
|---|---|---|---|
TagResource |
400 ResourceInUseException Attempt to change a resource which is still in use: Table is being deleted: <name> |
400 ResourceNotFoundException Requested resource not found: ResourceArn: <arn> not found |
200 |
UntagResource |
same | same | 200 |
ListTagsOfResource |
200 with the tags | same ResourceNotFoundException |
200 with the tags |
MongoDB and Cassandra keep the main answers after #550.
Cause
crates/engine/src/tagging.rs checks the table's existence through table_key_info and maps TableNotFound to ResourceNotFoundException. On main every backend's key-info read maps a DELETING row to TableNotFound; #550 makes PostgreSQL and SQLite read it as found (so the data plane is served, as the service does), and the tag path inherits that.
A TagResource accepted in the window writes an unconditioned tag row. On PostgreSQL the poller deletes the ARN's tag rows before the catalog row, so a tag written between those two statements survives the table and is inherited by the next table of that name. The measured sequence (tag, then drop) left no row behind; the hazard is the interleaving.
Fix shape
Refuse TagResource and UntagResource on a DELETING row with the TableBeingDeleted sentence #550 introduced (the tag path needs the table's status, which TableKeyInfo does not carry; a describe_table read or a status field on the key info), and serve ListTagsOfResource. One wire row per request, dual-target, on the held-window fixture tests/python/test_deleting_window_control_plane.py uses.
Found while reviewing #505.
- 主要语言
- Rust
- 星标
- 517
- 派生
- 60
- 平均合并
- 2 天 22 小时
- 30 天内合并 PR
- 25
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
ExtendDB/extenddb 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 2 天内回复
-
backend:mongodb bug
难度 2/5 1-3 小时 新手友好度 77/100
维护者通常 2 天内回复
-
backend:cassandra bug
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 2 天内回复
-
documentation
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 2 天内回复
-
backend:cassandra bug
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 2 天内回复
查看 ExtendDB/extenddb 的全部 Issue
相似的 Issue
-
needs triage
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
-
难度 2/5 1-3 小时 新手友好度 72/100
mozilla-services/syncstorage-rs#2715 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 70/100
-
documentation
难度 1/5 1 小时以内 新手友好度 82/100
physicsdolphin/nv-uefi-unlocker#53 · 4 个 reaction ·
维护者通常 1 天内回复