bullboard

Bull Board

Use native curl to call the dashboard's existing API, without adding wrapper scripts and without connecting directly to Redis. Before executing, read the HTTP API reference authentication and query sections; for write operations or when waiting on jobs, read the corresponding sections as well.

Environment and target

• Read the address, username, and raw password respectively from BULL_URL、BULL_USER、BULL_PASSWORLD。PASSWORLD is the spelling agreed upon by this skill and cannot be changed to PASSWORD, nor fall back to credentials from other services or the server-side password hash.
• BULL_URL represents the dashboard mount root address, which may include a path prefix; strip the trailing / and then concatenate /api/.... Do not store the actual address, account, or password in the skill.
• Explicit user configuration takes precedence. When variables are missing, check whether the project has already been configured via mise; if so, use mise exec -C <项目根目录> -- <命令> to load it, without outputting the full configuration or environment. If still missing, report the missing variables and do not automatically write configuration.
• When changing the address, verify the corresponding credentials, and do not automatically send the original site's credentials to other hosts. Use HTTP Basic only on confirmed trusted networks; use HTTPS on other networks.

Execution flow

1. Prepare a temporary authentication configuration, and verify the HTTP status and JSON structure with a minimal read-only request. Successful authentication only proves that the credentials were accepted; do not claim that the account role has been verified.
2. When the target is unknown, read the queue list once; use the complete name from the response to locate the queue, and do not guess based on similar names or tree-style display names. When the exact queue name and job ID are known, read the job details directly.
3. Query or perform authorized operations according to the user's goal. Before writing, verify the target, current status,readOnlyMode , and related capabilities; batch retry, cleanup, or emptying must have authorization for the corresponding scope, and single-job authorization does not extend to the entire queue. Do not ask again when explicit authorization already exists.
4. Report the target dashboard, queue, job ID, HTTP status, and necessary evidence. Job data, results, and errors may contain sensitive content; output only the redacted summary needed to fulfill the request.

Request and wait boundaries

• The default connection timeout is 10 seconds, and the total timeout for a single request is 60 seconds. A client timeout does not guarantee that the server-side query has stopped, and slow queries cannot be resolved by repeated retries.
• Lists default to 20 items per page; retrieve data by status and page number, and do not automatically scan all historical jobs./api/queues may still count all visible queues, whileactiveQueue only limits the job list; to track a known job, prefer the details endpoint.
• For ordinary queries, stop once the required data is obtained. Read logs on demand, preferring the range parameters supported by the server; when there is no pagination capability, do not invent parameters, and do not repeatedly fetch the full logs.
• After a retry, add, or run-early request returns, by default report the API result and stop, without querying the subsequent execution status or following logs. API success does not mean the job has finished executing.
• For state changes such as pause, resume, and delete, you may read back once to verify the effect; if it cannot be verified, report only the request result and do not expand into continuous waiting. Pausing a queue does not mean terminating a job that is currently executing.
• Poll only when the user explicitly requests waiting. The user's time limit takes priority; otherwise, poll once every 10 seconds for a total of up to 30 minutes, and state the limit at the start; a single wait must not exceed 60 seconds, with periodic feedback. Upon expiry, only end the local wait; do not cancel the task.
• Do not automatically resend when a write request times out, disconnects, or has an unclear result. For read-only requests encountering 429 or 5xx, you may retry at most twice according to Retry-After or a short backoff; do not block and wait in the default query for a long backoff—report that you will check again later.

Capabilities and Result Boundaries

Interfaces and fields are subject to the target deployment version; the latest upstream routes must not be treated as capabilities already supported by the current service. Existing read-only verification does not mean all write operations have been actually tested; unverified write capabilities should be checked against the corresponding deployment source code, routes, and permissions, without probing via real writes.

Progress is reported by the Worker, and results and logs depend on business records;progress=0 does not mean it was not executed, and an empty log does not mean there were no errors. Use the task details' status to determine the status, not just failedReason or isFailed, as they may retain historical failure information. Cleaned-up tasks cannot have their historical results restored through the panel, and a 404 must not be directly taken as success or deletion completion.