Repository navigation
feat(store): configured namespaces with stores of their own, placed by a resolver - #663
Open
yzabelle-go wants to merge 3 commits into
Open
yzabelle-go wants to merge 3 commits into
yzabelle-go wants to merge 3 commits into
Conversation
An @<name>/ id in a namespace configured under [namespaces.<name>] (document and object tables) keeps to that namespace's stores: its entities by id, what a run of its tasks records, and every entity and object that run writes, objects under a <name>/ key prefix. Reads no id places see the configured store and the running task's namespace, plus only the namespaces reading_namespaces() opens, so a service decides who reads which. A shared entity may not name a namespace's ids, a run never writes a new version of a shared entity, and a run's objects never go to the shared store. Routing is inert with no [namespaces] table. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A [namespace_resolver] (module:Class, namespace_of(entity_id, fresh=)) now says which ids are in which configured namespace, instead of an @<name>/ id prefix. Ids derived from a placed id (<id>__...) follow it (id_bases). Writes ask the resolver fresh and fail when it raises; a run asks once where its task is, an enclosing run's namespace winning. Configured stores refuse every @ id again, key_segment is unchanged from main, and the reference guard (a shared document naming a namespaced id) is gone: with a resolver it would cost a lookup per string written. TableNamespaceResolver lists ids in config, for tests and small deployments. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…d every store a multi-id filter names Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
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.
FD-5441 phase 2. A deployment can now keep some entities, and everything about them, in stores of their own. A
[namespaces.<name>]table names a document store and an object store, and a[namespace_resolver]says which ids are in which namespace. Ids derived from one (<id>__…) follow it.What goes to a namespace's stores:
Objects go under a
<name>/key prefix, so namespaces can share a bucket.Reads that no id places, such as lists or lookups by instance id, see only the shared store and the running task's namespace, unless a service opens more with
reading_namespaces(...). That lets a service show a namespace to its members only.Writes ask the resolver for a fresh answer and are refused if it can't give one. A run in a namespace never writes a new version of a shared entity, never updates a shared run record, and never writes objects outside its namespace's store.
This does nothing until a
[namespaces]table is configured. Task steps need no edits:get_object_store()was already run-scoped for@localruns and now is for configured namespaces too.TableNamespaceResolver, which lists ids in config, is the in-tree resolver, used by the tests.Validation:
tst/unit/store/configured_namespace_test.py(141 tests): routing, fail-closed writes, guards, objects, an artifact round trip, and the document-store conformance suite in three modes.clickin a subprocess's Python, and 1 that hangs on this machine's git credential helper. All 4 behaved the same before this change.Part of a three-PR set for restricted storage:
Merge order: this first, then a release. The other two don't need this one to merge, but they do nothing until it is released and pinned.
🤖 Generated with Claude Code


Confidence Score: 5/5
The PR appears safe to merge; both previous findings are fixed, and no new actionable issues were found.Summary
Adds configured namespaces with separate document and object stores, chosen by a resolver.
Diagram
%%{init: {'theme': 'neutral'}}%% flowchart TD Request[Store request] --> Kind{Read or write?} Kind -->|Read| IDs{IDs name namespaces?} IDs -->|Yes| Named[Search named stores] IDs -->|No| Visible[Search shared, running, and opened stores] Kind -->|Write| Resolve[Ask resolver for placement] Resolve --> Guard{Allowed for this run?} Guard -->|No| Reject[Reject before writing] Guard -->|Yes| Destination[Write to selected store]Reviews (2) · Last reviewed commit: "fix(store): refuse a run's upload for an..." · Reviewed by Greptile