Files
onyx/web
Wenxi 5858a6767e fix(craft): preserve approval outcomes and report expired requests (#16180)
## Description

Use one decision endpoint for Approve once, Approve for session, and
Reject. Concurrent session approvals lock the session before updating
requests to prevent conflicting lock order.

Keep approval outcomes available after decisions and reloads as compact,
neutral conversation rows. Details start collapsed. Expired rows state
that the action did not run; only pending requests show an attention
border and decision buttons. The server decides whether a request is
still live; a user's device clock cannot disable it. History includes
live requests and the 50 most recent outcomes. Polls read small status
records and refresh full history when statuses change.

The proxy still waits up to 180 seconds. This is a network wait, not
durable paused execution. Expired requests show Expired, and late
decisions return a conflict. Agent permission requests that cannot
resume fail scheduled runs with a clear reason. Losing an execution
lease aborts the agent.

The plugin editors and personal/task permission controls are in the
preceding PR, #16185. Approval queries remain in the existing Craft DB
module, as requested for this feature.

## How Has This Been Tested?

- Ten approval-card/history tests pass, including collapsed neutral
expiry, detail expansion, and live-request controls.
- A browser check confirmed the neutral expired row and unchanged
pending controls.
- 82 gate unit tests passed after restoring the Craft DB module.

- Earlier verification passed 21 approval API database tests, including
concurrent session grants, retries, conflicting decisions, history, and
expiry.
- Earlier local Kind checks covered concurrent grants, a browser clock
ten minutes ahead, and approved history after reload.
- A scheduled worker requested approval without an open browser;
approval resumed execution and produced the expected result.
- An actual 180-second timeout blocked forwarding and rejected a late
decision.
- Follow-up verification passed 39 approval/executor database tests, 550
proxy unit tests, and five route-contract tests.

## Additional Options

- [ ] [Optional] Please cherry-pick this PR to the latest release
version.
- [x] [Optional] Override Linear Check


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **New Features**
* Approval cards now offer **Approve once**, **Approve for session**,
and **Reject** in one flow, with session-wide approval available when
eligible.
* Session approval history now shows pending, approved, rejected, and
expired requests. Status updates are checked automatically, and changed
statuses refresh the history.
* Cards show approval deadlines and present completed requests as
compact, expandable outcomes.

* **Bug Fixes**
* Scheduled runs that need unavailable permissions now finish as failed
runs instead of waiting for approval.
  * Expired approval messages clarify that the action did not run.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-10-19 18:44:15 +00:00
..
…
…
…
…

This is a Next.js project bootstrapped with create-next-app.

Getting Started

Install bun: https://bun.sh/docs/installation Install all dependencies: bun install.

Then, run the development server:

bun run dev

Open http://localhost:3000 with your browser to see the result.

Note: if you are having problems accessing the ^, try setting the WEB_DOMAIN env variable to http://127.0.0.1:3000 and accessing it there.

Tip

Packages are installed automatically when switching branches after package.json changes with pre-commit configured.

Connecting to a Cloud Backend

To test your local frontend development server against a cloud backend (e.g., staging or production), create a .env.local file in the web/ directory with the following configuration:

# Point local dev server to cloud backend
INTERNAL_URL=https://st-dev.onyx.app/api

# Debug auth cookie for authenticating against remote backend
# This cookie is automatically injected into API requests when in development mode
# To get this value:
#   1. Go to https://st-dev.onyx.app (or your target backend URL) and log in
#   2. Open DevTools (F12) → Application → Cookies → [your backend domain]
#   3. Find the "fastapiusersauth" cookie and copy its value
#   4. Paste the value below (without quotes)
# Note: This cookie may expire, so you may need to refresh it periodically
DEBUG_AUTH_COOKIE=your_cookie_value_here

By default, this does NOT override existing cookies, so if you've logged in previously, you may need to delete the cookies for the localhost domain.

Important notes:

  • The .env.local file should be created in the web/ directory (same level as package.json)
  • After creating or modifying .env.local, restart your development server for changes to take effect
  • The DEBUG_AUTH_COOKIE is only used in development mode (NODE_ENV=development)
  • If INTERNAL_URL is not set, the frontend will connect to the local backend at http://127.0.0.1:8080
  • Keep your .env.local file secure and never commit it to version control (it should already be in .gitignore)

Testing

This testing process will reset your application into a clean state. Don't run these tests if you don't want to do this!

Bring up the entire application.

  1. Install playwright dependencies (run bun install first so bunx resolves to the repo-pinned Playwright in node_modules instead of fetching the latest version)
bun install
bunx playwright install
  1. Run playwright (the playwright script expands to playwright test)
bun run playwright

To run a single test:

bun run playwright landing-page.spec.ts

If running locally, interactive options can help you see exactly what is happening in the test.

bun run playwright --ui
bun run playwright --headed
  1. Inspect results

By default, playwright.config.ts is configured to output the results to:

web/output/playwright/
  1. Visual regression screenshots

Screenshots are captured automatically during test runs and saved to web/output/screenshots/. To compare screenshots across CI runs, use:

ods screenshot-diff compare --project admin

For more information, see tools/ods/README.md.