Claude finished @Yeraze's task —— View job

PR Review

• Read changed files
• Analyze code quality and best practices
• Check for potential bugs or issues
• Review test coverage

This is a small, focused fix that addresses a real UX pain point. The change is well-scoped and the code quality is solid. A few observations:

meshcoreManager.ts — Timeout reduction

The 12 s timeout is reasonable for the described two-round-trip scenario (getContacts() + setContactPath()). The comment at src/server/meshcoreManager.ts:2297–2298 explains the reasoning clearly.

Minor observation: The timeout detection uses a substring check (response.error?.includes('timeout')). This works fine for now, but it couples the hint to whatever error string meshcore.js happens to produce on timeout. If that upstream error message ever changes (e.g., capitalisation or phrasing), the hint silently disappears without any test failure. A more robust approach would be a typed error code or a dedicated isTimeout flag on BridgeResponse — but that would be a larger refactor and is out of scope for this fix.

Consistency note: The shareContact path at meshcoreRoutes.ts:713 already distinguishes timeouts from other failures and returns 504 instead of 409, with a regex test (/did not respond|timeout/i). The set_out_path path still returns 409 on timeout. It may be worth aligning these so timeouts consistently yield 504 (Gateway Timeout), but again that's a broader cleanup rather than a blocker for this fix.

meshcoreRoutes.ts — Error message

The new message ("Set out_path failed — the device did not respond in time. Verify the device is connected and try again.") at line 673 is an improvement over the old generic message.

Observation: The old error message distinguished "contact may be unknown" from "source disconnected" — these were useful hints for cases where the command failed for a reason other than a timeout. With this change, any non-success from setContactOutPath now returns the timeout-specific message, even if the failure was actually because the device was not connected at all or the contact was missing. This is a minor accuracy regression for the non-timeout failure modes. Given the simplified boolean return from setContactOutPath, there isn't currently a way to differentiate these at the route layer without a more substantial refactor — just worth noting.

Test coverage

The existing test at meshcoreRoutes.test.ts:1672 covers the 409 path for setContactOutPath returning false, but doesn't assert the error message body. Adding a check like expect(response.body.error).toMatch(/did not respond in time/) would ensure the improved message is tested and doesn't silently regress. Not a blocking issue given it's a display string, but a simple addition.

Summary: The fix is correct and well-targeted. The 12 s timeout is sensible, the log hint is helpful for operators, and the new error message is more actionable for users. The observations above are all minor polish items and none are blockers for merging.