Review local branch against remote state

next steps

—

key decisions

—

open questions

—

next steps

—

key decisions

• Remove dead tracing keys (sql_queries, sql_origin, views, queue_*) from config/sentry.php and add block comment explaining why TracingServiceProvider is deliberately unregistered.
• Keep TracingServiceProvider unregistered to avoid duplicate request middleware.
• Commit without author attribution as requested.
• Leave CLAUDE.md and AGENTS.md untracked (symlink).

open questions

—

next steps

—

key decisions

—

open questions

—

next steps

—

key decisions

• Replace bugsnag log channel with sentry at 'error' level to preserve alerting for standalone Log::error() calls that are not attached to thrown exceptions.
• Set sentry log level to 'error' (not 'warning') to prevent circular reporting of Sentry's own warning-level self-diagnostics.
• Skip replicating Bugsnag's OOM memory bump behavior; not needed and Sentry SDK explicitly declines it.

open questions

—

next steps

• Complete analysis of the 23 commits on master not in staging to determine if they are meaningful or just merge noise.
• Recommend merging strategy to reconcile staging with master.

key decisions

—

open questions

• Whether the user migrated to a different staging branch (the user mentioned a possible migration).

next steps

• Build App\TDR\WordPress\AuthCookie validator class
• Update DashboardAuth middleware to try cookie first, fall back to email/password
• Add WORDPRESS_LOGGED_IN_KEY and WORDPRESS_LOGGED_IN_SALT env vars
• Write tests for the new auth path

key decisions

• Use passive read-only verification of WordPress auth cookie; no writes to WordPress.
• Read raw Cookie header instead of request cookie bag because EncryptCookies middleware nulls unknown cookies.
• Two WordPress installs exist on domain; wrong install's cookie fails signature check harmlessly.

open questions

• Whether the cookie Path attribute is / or narrower; user's paste from a request header indicates it is sent to /api/.

next steps

• Set WORDPRESS_LOGGED_IN_KEY and WORDPRESS_LOGGED_IN_SALT on staging server .env from shop wp-config.php
• Deploy and verify /dashboard loads without login form when WP admin session is active

key decisions

• Env keys named WORDPRESS_LOGGED_IN_KEY/SALT to match shop server's existing env vars for consistency across hosts.
• Fallback email/password flow retained for local dev where WP admin session may not exist.
• Validate per-request so WP logout immediately revokes dashboard access.

open questions

—

next steps

• Run rm -f bootstrap/cache/*.php on staging server before composer2 install
• Run composer2 install, php artisan config:cache, php artisan queue:restart
• Verify sentry tracing works with tdr:test-sentry and a browser request

key decisions

• Use config() for trace sample rates instead of env() because production caches config and env() returns null after cache.
• Add rate_* keys under sentry.tracing array; sentry-laravel strips the tracing array before SDK sees it, so custom keys are safe.

open questions

—

next steps

—

key decisions

—

open questions

—

next steps

• Manually deploy master to production: rm -f bootstrap/cache/*.php, composer2 install --no-dev, php artisan config:cache, php artisan queue:restart
• Update local remote URL to git@github.com:The-Darkroom/tdr-fos.git
• Verify /api/dashboard and /api/dashboard/api/stats on production

key decisions

• Use git merge --no-ff to maintain explicit merge commit on master per repo's historical pattern.
• Confirm merge-tree shows zero conflicts and no content loss from master's old revert-of-staging-merge.

open questions

—

next steps

• Rewrite startTransaction to use new TransactionContext(...) constructor instead of ::make()
• Fix setOp/setName calls that chain on void setters (separate lines)
• Adjust continueTrace call in middleware for 3.x API
• Test with SENTRY_DSN set locally to verify transaction creation

key decisions

• Must use SDK 3.x API since PHP 7.4 cannot run SDK 4.x (requires PHP 8.1).

open questions

• Are there any other SDK 4.x calls in the codebase beyond the two identified files?

next steps

• Redeploy prod host: rm -f bootstrap/cache/*.php, composer2 install --no-dev, config:cache, queue:restart to stop warnings.

key decisions

• Used NullTransport via TransportFactoryInterface to allow real tracing path to execute in test without network.
• Set actor_ref to claude-code:tdr-fos in flower brief.

open questions

—

next steps

• Add composite index (created_at, customer_id) to mobile_api_requests in thedarkroom repo migrations to eliminate full scans.

key decisions

• The index must be created in tdr/thedarkroom repository where the table's migrations live, not in tdr-fos.

open questions

• What exact external client (browser, monitor, or script) is polling the dashboard stats endpoint on an interval?

next steps

• Agent in tdr/thedarkroom should review and implement the migration following 4.2 convention and online DDL best practices.
• Apply migration off-peak manually on production MySQL.

key decisions

• One composite index (created_at, customer_id) covers both count(distinct customer_id) filter and range scans for other dashboard queries; no separate created_at index needed.
• Migration will use ALGORITHM=INPLACE, LOCK=NONE for online index build.

open questions

—

next steps

• Complete review of hotfix for correctness, caching, error handling.
• Commit properly to staging branch to avoid conflict on next deploy.
• Deploy via normal flow.

key decisions

—

open questions

• Should the hotfix cache the fallback orders response to avoid repeated FOS API calls on every profile load?
• Does error handling need improvement (the diff shows only a success check)?

next steps

—

key decisions

• The raw hotfix should not be committed as-is; a proper implementation must use the existing Cache::remember pattern with try/catch and error logging.

open questions

• Will Daniel confirm that a bounded FOS call during profile load (once per 5 min per user) is acceptable behavior?

next steps

—

key decisions

• Use Cache::remember instead of Cache::get in show() so cold cache fetches from FOS once per 5 minutes per user.
• Wrap FOS call in try/catch to log errors and return null instead of crashing the profile.
• Keep the same 300-second TTL and error-logging pattern from the original recentOrders() method.

open questions

• Does Daniel confirm the reversal of the 'no FOS during profile load' stance? The old code deliberately avoided FOS calls on profile load for latency; now it makes one bounded call per 5 min per user.

next steps

• Commit changes when ready
• Consider confirming with Daniel that the new FOS call on profile load is acceptable

key decisions

• Use Cache::remember with 5-minute TTL to limit FOS calls to once per user per 5 minutes
• Wrap FOS call in try-catch to prevent profile 500 on FOS failure
• Pre-warm cache in existing tests to keep them focused on their original intent (addresses, no FOS)

open questions

• Whether the team/PO is okay with the profile endpoint now making an outbound HTTP call on cold cache (latency impact)