Skip to content

Gate archival photo capture on the absence of a BLE transfer id - #3616

Open
PhilippeFerreiraDeSousa wants to merge 1 commit into
devfrom
pferreira/os-1796-asg-save-ble-gate
Open

Gate archival photo capture on the absence of a BLE transfer id#3616
PhilippeFerreiraDeSousa wants to merge 1 commit into
devfrom
pferreira/os-1796-asg-save-ble-gate

Conversation

@PhilippeFerreiraDeSousa

@PhilippeFerreiraDeSousa PhilippeFerreiraDeSousa commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

Scope

Part 2a of OS-1796: a one-line routing change in PhotoCommandHandler so save=true and a BLE transfer can coexist.

Today save && webhookUrl.isEmpty() unconditionally routes to the local-save-only capture path. The upcoming phone-delivery destination in the Bluetooth SDK sends transferMethod: ble + bleImgId + save (for a kept glasses-gallery copy) with no webhookUrl — on current firmware that shape would archive on the glasses and never start the BLE transfer, leaving the phone to time out. A request carrying a bleImgId has a delivery leg, so the archival route now additionally requires an empty bleImgId.

No behavior change for any request shape phones send today: the phone app always supplies a webhookUrl, and archival captures from direct BT-SDK callers carry no bleImgId.

This needs to roll out via the firmware train before the SDK-side destination change ships (release ordering only; both directions remain compatible in the interim).

Test evidence

:app:testDebugUnitTest --tests "*PhotoCommandHandlerTransferMethod*" — 6 tests, 0 failures, including two new cases: save+bleImgId+no-webhook rides takePhotoForBleTransfer (and never the local-save path), and save-only without bleImgId still routes to takePhotoForLocalSave.


Note

Medium Risk
Changes photo command routing on firmware; wrong gating could break BLE delivery or archival saves, but scope is a single condition and is covered by new unit tests.

Overview
Archival vs BLE routing for take_photo is tightened so save=true with an empty webhookUrl no longer always uses the local-save-only path.

The local-save shortcut now requires bleImgId to be empty as well. Requests with save, no webhook, but a bleImgId (e.g. transferMethod: ble from the BT SDK for phone delivery plus a gallery copy) go through the normal capture pipeline and takePhotoForBleTransfer instead of being treated as glasses-only archival captures that never start BLE.

Tests add two unit cases: save + bleImgId + no webhook must call BLE transfer and never local save; save with no webhook and no bleImgId still uses local save.

Reviewed by Cursor Bugbot for commit 15eaf44. Bugbot is set up for automated code reviews on this repo. Configure here.

A take_photo with save=true and no webhookUrl currently always routes
to the local-save-only capture path, even when it carries a bleImgId —
which means a phone-delivery request that also wants a gallery copy
would save on the glasses and never start the BLE transfer, leaving
the phone to time out.

A request with a bleImgId has a delivery leg, so only treat
save-without-webhook as an archival capture when there is also no
bleImgId. No behavior change for any shape phones send today (the
phone app always supplies a webhookUrl, and archival captures from
BT-SDK callers carry no bleImgId).
@github-actions

github-actions Bot commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

📋 PR Review Helper

📱 Mobile App Build

Waiting for build...

🕶️ ASG Client Build

Build failed (commit 15eaf44) - View logs


🔀 Test Locally

gh pr checkout 3616

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 15eaf44bf7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

// A request carrying a bleImgId DOES have a delivery leg (BLE to the phone) and
// must go down the normal pipeline even with save=true and no webhookUrl: that
// shape is phone-delivery with a kept gallery copy, not an archival capture.
if (save && webhookUrl.isEmpty() && bleImgId.isEmpty()) {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Keep local-save SDK payloads on the archival path

When a current Bluetooth SDK caller uses the supported requestPhoto({save: true, webhookUrl: null, ...}) shape, both Mentra Live serializers still generate a nonempty bleImgId even though no delivery was requested, and transferMethod defaults to auto. This condition therefore stops routing that request to takePhotoForLocalSave; it instead attempts an upload to an empty URL or an untracked BLE transfer because the phone only registers blePhotoTransfers when a webhook is present, causing the request to fail or time out instead of returning the local capture response. Gate this exception on an explicit BLE delivery method/destination rather than on the automatically generated fallback ID alone.

AGENTS.md reference: AGENTS.md:L136-L138

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant