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

[bdunncompany]

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:

Target	created_at (UTC)	fetched_at	completed_at	elapsed
macOS arm64	2026-05-02 18:25:09	18:25:10	18:25:52	43s
macOS x64	2026-08-26 22:38:32	22:38:33	22:39:15	43s
Windows	2026-09-09 18:32:18	18:32:18	18:34:55	2m37s

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.

[rustdesk]

@21pages

The macos build server works normally on our side.

[21pages]

Could you please try creating a new custom client configuration and building it again?

[bdunncompany]

Resolved, and the fault was on our side. Apologies for the noise.

The build had actually succeeded. The job I reported as never fetched shows, in our own database:

created_at   01:18:14
fetched_at   01:18:15
completed_at 01:18:56
file         bdunnremote-arm64.dmg
state        done

I have downloaded that DMG and confirmed it is a correct arm64 build.

My error: I was polling our server's local custom_client.status row over SSH, and it still read {created_at, id, waiting_length} with no state for the whole time I watched. It only reflected completion once I opened the Custom Clients page in the console. So the status I was reading was stale, not the build.

Everything in my original report follows from that one bad instrument, and I withdraw it.

Two things that might still be worth a look, offered as observations rather than claims:

1. If the local status row is only refreshed when the console page is opened, then anyone automating against it, as I was, will see a completed build as permanently pending. A note in the docs that the authoritative state comes from the console or the build service, not the local row, would have saved me this.
2. Build artifacts appear to expire. A client that built 2026-08-26 still shows a Download link, but the URL returns {"error":"File not found"}. A visible expiry or a disabled link would make that clearer than a 404.

Neither is blocking us. Thanks for the quick response, and sorry for the false alarm.

[21pages]

If the local status row is only refreshed when the console page is opened, then anyone automating against it, as I was, will see a completed build as permanently pending. A note in the docs that the authoritative state comes from the console or the build service, not the local row, would have saved me this.

Closing the Custom Clients page does not affect the build. When the page is opened again, it uses the saved job ID to fetch the latest status from the build service and updates the local database.

Build artifacts appear to expire. A client that built 2026-08-26 still shows a Download link, but the URL returns {"error":"File not found"}. A visible expiry or a disabled link would make that clearer than a 404.

Build artifacts are retained for 24 hours. This has already been addressed in newer versions: expired builds are now shown as expired with an option to rebuild, instead of displaying a stale Download link.