Known issues¶
Not a product
This documents an internal test environment. See the overview for what POC Sandbox is and is not.
What is known to be limited or broken, and what to do about it.
The sandbox has no per-person identity¶
Status: by design, in POC mode only
In POC mode the portal authenticates with one shared key. Every action is therefore attributable to "whoever holds the key" and no further. The audit trail records what happened but not who did it.
What to do: nothing, in the sandbox. But never carry this mode toward real
issues — the platform refuses to start with POC_MODE=true outside a test
environment for exactly this reason.
Every app routes to the same repo¶
Status: by design, in POC mode only
The app dropdown still works, and the app: label is still written correctly, but
the issue lands in the sandbox rather than in that app's repo.
What to do: to test real routing, use a non-POC environment. The app: label
on the sandbox issue tells you where it would have gone.
Issues are never triaged¶
Status: by design
Nothing watches the sandbox. No one is notified, no automation runs, and nothing is answered.
What to do: close your own test issues when you are finished with them.
Attachments outlive their issues¶
Status: open
Closing or deleting a sandbox issue does not remove files uploaded to it. The attachment store keeps its own records, and deleting a GitHub issue does not reach them.
What to do: in the sandbox, ignore it — the data is synthetic. It is recorded here because the same behaviour applies in production, where it matters, and anyone testing deletion should know the two stores are cleaned separately.
Release history in the portal is empty¶
Status: blocked, external
The portal's Releases page reads GitHub releases through the production GitHub App, which does not exist yet. The page answers with an error rather than an empty list.
What to do: nothing. It resolves when the real GitHub Apps are registered.