macOS arm64 custom client: job is created but status never advances. What should we check?

Self-hosted rustdesk-server-pro, hbbs 1.8.2.

We are trying to build a macOS arm64 custom client. Each attempt returns a job
id, and the stored status then never gains fetched_at, state or file for as
long as we watch it. We would like help working out where it is stopping, and
whether arm64 macOS builds are currently expected to work.

What we observe. After POST /api/custom-clients/{guid}/create, the status
value stays shaped like this:

{"created_at":"...","id":"...","waiting_length":0}

Four attempts, the first submitted 2026-09-12 18:29 UTC and the last
2026-09-14 01:18 UTC. Each was polled for at least 150 seconds; the first was
still unchanged more than 27 hours later. We never saw the status advance. We can
only see our own server's stored status, so we cannot tell from here whether the
job reached your build service at all.

Successful builds on this server, for comparison:

In each of those, fetched_at appeared within about a second. Our most recent
arm64 success is 2026-05-02, so we cannot say when arm64 last worked.

What we have tried, and what it does and does not tell us:

• Re-triggered the arm64 client that built successfully on 2026-05-02. Same result.
  This makes "one bad record" less likely, but does not exclude a shared cause.
• Compared the info JSON of a client that builds against one that does not:
  11 keys each, identical except arch (x64 vs arm64). This is a comparison of
  that one field only; something outside it could still differ.
• Restarted hbbs. It came up clean and the license check passed. The next
  submission still did not advance. This argues against transient process state,
  not against a persistent server-side or account-side cause.
• From the server, rustdesk.com, api.rustdesk.com and admin.rustdesk.com return
  HTTP responses, and the iptables OUTPUT chain policy is ACCEPT. We have not
  verified the actual build transaction from inside the container.
• docker logs hbbs shows no WARN or ERROR lines and nothing referencing the
  build. A bounded negative observation only.

Questions:

1. Are macOS arm64 custom client builds currently supported and working?
2. Is there a per-license build quota or rate limit we might have reached?
3. Is there any log or API that shows whether a submitted job reached your build
   service, so we can tell a local submission failure from a remote one?
4. Is waiting_length: 0 with no fetched_at ever normal?
5. Is there a supported way to download an already-built client? POST /api/custom-clients/{guid}/download returns {"error":"Invalid action"}, and we
   could not find the correct route.

Disclosure about our own testing. During this investigation we made a mistake
of our own: while restoring a row we had overwritten, we wrote a value into
custom_client.status with SQLite storage class BLOB instead of TEXT. That was our
error, not a product defect. It was introduced at 2026-09-12 22:15 UTC and repaired
at 2026-09-14 01:17 UTC, immediately before the final attempt below. We have
discarded every observation made inside that window, including an earlier claim
that Windows builds were also affected; we no longer assert that.

The attempt described above at 2026-09-14 01:18:14 UTC was submitted after the
repair. Before submitting it we confirmed that every row's status was TEXT again
and that GET /api/custom-clients?current=1&pageSize=20 returned all 9 records with
no error. We then polled for 150 seconds and the status never advanced. Of the four
attempts listed, that last one is the clean one; it alone would be sufficient
grounds for this question.

A behaviour you may want to look at, with the caveat that we caused it. While
that malformed value was present, GET /api/custom-clients?current=1&pageSize=10
returned HTTP 200 with an error body and zero rows, and the Custom Clients page
rendered "No data" even though nine records existed:

error occurred while decoding column "status: _": mismatched types;
Rust type `core::option::Option<sqlx_core::types::json::Json<serde_json::value::Value>>`
(as SQL type `TEXT`) is not compatible with SQL type `BLOB`

To be clear about scope: we introduced that value ourselves with a direct database
write, and we have not shown that any supported RustDesk operation can produce
it. So this may be entirely self-inflicted and not worth your time.

The part that seemed worth mentioning anyway is the failure mode rather than the
cause: a decode error on one row returned 200 with an empty list, so the UI showed
an empty table instead of surfacing the error. We spent a while thinking the records
were gone. We are not suggesting you skip or drop undecodable rows, which would hide
real data. Surfacing the decode failure to the caller would have saved us the
confusion.

Start with POST /api/custom-clients/{guid}/create and compare its status progression with the documented successful attempts; inspect hbbs logs and verify the build transaction from inside the container. Check whether the macOS arm64 request reaches the remote build service, and define done as identifying the stopping point or confirming the supported route for status and downloads.