Skip to content

[probe] Can a package-declared permission set ever enter trash? — the one path the #11513 save-door lock does not cover #11725

Description

@os-sam

Split out of #11513 at closure so a named residual does not die in a closed card's comments. Filed unassigned, no pm:queue — grading is triage's field.

This may be a no-op card, and that is a legitimate outcome. It is a probe, not a known defect.

The residual

PR #11702 (merged e170b0ae) locks the save door: an insert or update targeting a package-declared permission set is refused with NOT_OVERRIDABLE/403 before the metadata write. Its author named one leg the lock does not cover, rather than leaving it to be discovered:

the restore leg of the write-through still re-authors a restored record's body into metadata without the lock. It runs after the record is already back, where a throw would strand the caller with a healthy-looking row and no way to hear about it — the reason its neighbours catch rather than throw. Reaching it needs a trashed record for a package-declared name, which the delete path does not produce (it resets instead).

The contract reviewer accepted this as a residual, not a defect, and suggested exactly one cheap follow-up — which is this card.

The probe, and the only question it has to answer

Can a record whose name is package-declared enter trash at all?

  • If no — the restore leg is unreachable for this class, the residual is closed by construction, and the right outcome is to record that measurement and close this card. Ideally with a pin so a future change to the delete path cannot silently open the leg.
  • If yes — then there is a real second door into the silent-overlay state that Studio save of a package-declared permission set forks it into a silent, undiscoverable overlay #11513 exists to close, and it needs its own scoping (⚠️ noting the author's reason the lock is not simply copied there: a throw after the record is restored strands the caller with a healthy-looking row and no signal, which is why the neighbouring paths catch rather than throw — so "add the same refusal" is not obviously the answer).

Why it is worth the probe rather than an assumption

The delete path "resets instead of trashing" for packaged sets is documented behaviour, and documented behaviour is what the #11513 family has repeatedly found to be true in one place and not anothercustomized was forced false on exactly the shape it needed to describe, and managed_by turned out measurably wrong in both directions as a provenance proxy. So: measure, do not transcribe.

⚠️ A zero-hit here needs a positive control — establish that the instrument can see a record entering trash at all (on some other object) before concluding that a packaged set cannot.

Not measured

Everything above. Nothing has been run for this card; it exists to be run.

Refs: #11513 (the ruling and the save-door lock) · PR #11702 (e170b0ae, where the residual is stated in the PR body and the module header) · #11703 (the sanctioned clone path's completeness fix)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions