aglinxinyuan opened a new issue, #7381: URL: https://github.com/apache/texera/issues/7381
### Task Summary Three of the four API clients under `agent-service/src/api` have no spec: `auth-api.ts`, `workflow-api.ts`, and `backend-api.ts`. Only `compile-api.ts` is covered. `auth-api` is the one that decides whether a request is authenticated at all, and none of its decisions are pinned. Several are policy choices that read like oversights and would be easy to "fix" in the wrong direction: | Input | Result | Why it matters | |---|---|---| | token with no `exp` | **valid** | tokens minted without an expiry never expire | | malformed token | **invalid** | the decode error is swallowed and reported as expired, not thrown | | payload with no `role` | `REGULAR` | absent must mean least privilege | | `bearer abc` / `BEARER abc` | `abc` | the scheme is matched case-insensitively | | two-segment token | throws | the only thing rejecting an unsigned token whose payload parses | `workflow-api` round-trips the workflow `content` as a **nested JSON string** in both directions — the request sends `content: JSON.stringify(content)` and the response is re-parsed when it comes back as a string. Sending the object directly is the obvious-looking mistake, and the backend rejects it. `backend-api` hands out module-level config shared by every client; `getBackendConfig` returns a spread copy so one caller cannot repoint everyone else's endpoints. ### Task Type - [ ] Refactor / Cleanup - [ ] DevOps / Deployment / CI - [x] Testing / QA - [ ] Documentation - [ ] Performance - [ ] Other -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
