Skip to content

Device reliability

Device Control When the Result Is Uncertain

A timed-out unlock can still be in flight. I separated requested authorization, vendor acceptance and active permission so retries and background locking would not contradict each other.

3 min read

Senior AI Engineer · M.S. Computer Science, Tsinghua University · See the products I built

In this article · 5 sections
A device action reserves a lease, persists pending authorization, dispatches to the vendor and only then activates permission. Explicit authentication rejection permits one checked retry. An unknown outcome retains short isolation.
How it works. Pending, rejected, unknown and active are different operational states. HTTP success alone may still contain a business-level authentication rejection.Open full size ↗

The engineering decisions

  • Persist pending authorization before dispatch and activate it only after the required confirmation.
  • Coordinate manual control, booking control and idle locking through the same lease boundary.
  • Retry explicit authentication rejection narrowly, and treat a timeout as an uncertain outcome.

An unlock needed a durable meaning

Staff needed temporary device access for demonstrations, maintenance or training. An isolated unlock command did not tell the idle-locking task why the screen should remain available. I modeled the action as an administrator authorization with a purpose, actor and explicit duration.

The authorization was stored in the database so closing the browser or restarting the simulator did not erase the server-side decision. Expiry was checked when evaluating permission, rather than depending on a cleanup job first deleting the record. The later explicit unlimited option was a capability staff could select, not a blanket grant to real devices.

Persist intent before claiming success

The first authorization wrote pending state, dispatched the command and became active only after the vendor success and final persistence step. A failed renewal retained the previous expiry instead of extending it or revoking a still-valid authorization. Failures in the final write could not create a valid idle-lock exemption.

Manual Lock revoked authorization before contacting the vendor, allowing a later idle inspection to retry if that command failed. A normal booking enable consumed the old manual authorization atomically with device ownership. Ending the booking could not revive an earlier administrative permission.

Protect the physical target, not just a row

The authorization was bound to organization, store, bay, physical control identity, stable venue identity and server region. Rebinding equipment or moving it between regions could not carry the old permission along. Manual control, booking enable and idle inspection shared a short device lease.

A timeout has a different meaning from a rejected request. The command may still arrive late. The implementation retained short isolation for an unknown result to reduce the chance that a late unlock collided with a new session. It did not label the authorization active merely because a network call had started.

GolfJoy Play dashboard with booking and device-status counters
In the product. Public venue-guide test screen. Operational counters provide context, but do not establish that an individual physical screen accepted a command.Open full size ↗

Handle the vendor’s two rejection envelopes

One production failure returned HTTP 200 while the business response contained an authentication rejection. The old client refreshed only after HTTP 401 or 403. I recognized both envelopes and allowed at most one reauthentication and resend after an explicit rejection.

That resend still rechecked device ownership and lease authority. Timeouts, invalid JSON, general business failures and server errors did not gain a blanket retry. Later September records identified additional lease-release failure paths and kept those follow-up changes separately scoped rather than treating a merged fix as already deployed.

Separate service evidence from a screen observation

The September authorization work included SQL and simulated-provider tests for expiry, failed renewals, scope changes, lease loss and booking takeover. The recorded vendor contract covered business-level rejection and bounded retry. Production reads confirmed that an existing authorization suppressed idle locking while other devices continued to be inspected.

That is evidence about server-side behavior. The release notes retained physical simulator restart and display behavior as field observations to be checked separately. A reliable account of device engineering keeps those two kinds of evidence distinct.

Project context and evidence

Written from my September 2026 administrator screen-authorization and vendor-authentication repair records. Public links below support the product and attribution context. Internal project records are summarized, with customer records, credentials, and employer source code omitted.

Related engineering articles

All articles ↗