Skip to content

agent, control-plane: remove the storage-mappings directive; pin authorization on the GraphQL path (7/7) - #3351

Open
bbartman wants to merge 1 commit into
bmb/2781-stack-6-admin-endpointsfrom
bmb/2781-stack-7-storage-mappings-directive
Open

agent, control-plane: remove the storage-mappings directive; pin authorization on the GraphQL path (7/7)#3351
bbartman wants to merge 1 commit into
bmb/2781-stack-6-admin-endpointsfrom
bmb/2781-stack-7-storage-mappings-directive

Conversation

@bbartman

Copy link
Copy Markdown
Contributor

Description:

Part 7 (final) of the snapshot-authorization stack (follows the stack-6 admin-endpoints PR). Decomposed from #3300, which this completes.

The storage-mappings directive is deleted rather than migrated: the GraphQL storage-mapping mutations superseded it on 2026-03-16 (the last routine production application). Removed with it:

  • the agent-side handler (crates/agent/src/directives/storage_mappings.rs) and its Directive variant;
  • user_has_admin_capability — which also removes a loose-direction prefix comparison that let a sub-prefix admin rewrite the whole tenant's storage mapping;
  • the directive's .sqlx query metadata.

The still-shared persistence helpers move out of directives/ to control-plane-api/src/storage_mappings.rs, and the two import sites (create_data_plane, the GraphQL mutations) retarget to the new location.

The authorization boundary the directive used to (incorrectly) hold is now pinned on the GraphQL path instead: new integration tests deny the sub-prefix and attenuated raw-admin shapes.

The agent crate now sets recursion_limit = 256: laying out the publication pipeline's nested poll future needs a ~130-deep rustc query descent, over the 128 default. Earlier trees compiled only because the since-deleted directive chain happened to pre-compute shared sub-layouts — the raise makes that accident explicit, per rustc's own guidance.

Verified locally: cargo nextest run -p control-plane-api -p agent — 297/297 passing at this branch tip, including the new GraphQL denial tests.

Workflow steps:

Applying a storage-mappings directive is no longer possible; storage mappings are managed exclusively through the GraphQL mutations (the dashboard path since March 2026).

Documentation links affected:

None — the directive was never user-facing documentation-wise; the GraphQL path is already the documented one.

Notes for reviewers:

  • The security-relevant part is the removal of user_has_admin_capability and its loose prefix comparison, and the new GraphQL denial tests in crates/agent/src/integration_tests/graphql/mutations/storage_mappings.rs that pin the corrected boundary — review these first.
  • crates/control-plane-api/src/storage_mappings.rs is a move of the persistence helpers, not new logic; review the move diff for what was dropped (the directive-only pieces) rather than line-by-line.
  • The bulk deletion of the agent handler is safe to skim; the DirectiveHandler::new signature change (drops logs_tx) ripples into main.rs and the test harness.
  • recursion_limit = 256 in crates/agent/src/lib.rs carries its rationale in a comment; it is required by this PR's deletion, not incidental.

…orization on the GraphQL path

The GraphQL storage-mapping mutations superseded the directive on 2026-03-16
(the last routine production application), so the agent-side handler, its
Directive variant, and user_has_admin_capability are removed — the latter
taking with it a loose-direction prefix comparison that let a sub-prefix
admin rewrite the whole tenant's mapping. The still-shared persistence
helpers move out of directives/ to control-plane-api/src/storage_mappings.rs.

That authorization boundary is now pinned on the GraphQL path instead:
sub-prefix and attenuated raw-admin shapes are denied, with tests.

The agent crate now sets recursion_limit = 256: laying out the publication
pipeline's nested poll future needs a ~130-deep rustc query descent, over
the 128 default. Earlier trees compiled only because the since-deleted
directive chain happened to pre-compute shared sub-layouts.
@GregorShear

Copy link
Copy Markdown
Contributor

Is there a reason this sits on top of the stack? Correct me if i'm wrong but AFAICT this could be merged independently

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants