Skip to content

Distinguish invalid Dag access control from FAB backend failures - #74787

Closed
ephraimbuddy wants to merge 1 commit into
mainfrom
codex/dag-processor-fab-validation
Closed

ephraimbuddy wants to merge 1 commit into
mainfrom
codex/dag-processor-fab-validation

Conversation

@ephraimbuddy

@ephraimbuddy ephraimbuddy commented Oct 15, 2026 •

Copy link
Copy Markdown
Contributor

Superseded by #74788 after renaming the branch to dag-processor-fab-validation.

Report malformed Dag access-control definitions as validation errors. Backend failures keep their original exception type, allowing atomic parse publication to reject invalid metadata while retrying infrastructure failures.

Layer 1 of the seven-part split of #74233. This layer can be reviewed and merged independently.

Focused security tests: 49 passed, 1 skipped. Selected provider suites: 1,346 non-database tests passed (29 skipped); 1,057 database tests passed (6 skipped). One existing provider-discovery test timed out at 60 seconds, including an unchanged isolated retry. Regular and manual checks, all-provider mypy, and common.compat/FAB documentation builds passed.


Was generative AI tooling used to co-author this PR?
  • Yes — Codex (GPT-6)

Generated-by: Codex (GPT-6) following the guidelines

Callers need to distinguish malformed Dag access control from permission
backend failures so they can report invalid input without suppressing
transient infrastructure errors. Existing FabException handlers remain
compatible.
@ephraimbuddy
ephraimbuddy deleted the codex/dag-processor-fab-validation branch October 15, 2026 09:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant