From support tickets to verified fixes: a full day across Columbia Games checkout and digital delivery

Situation

At Columbia Games, development and support converged across layers in a single day: customer library entitlements, shipping tariffs, PayPal payments, catalogue data, legacy PDF files, admin configuration context, media caching and email coordination. Many questions repeated across separate threads; some were already addressed in code, others still needed live verification, and a few required a business decision rather than more engineering. The goal was not to mark everything 'done'. It was to connect every claim to traceable evidence and keep a reliable view of what was still outstanding.

Approach

We started by inventorying the requests, then examined higher-risk cases at the layer where the truth lives: GitHub pull requests and commits, code actually running inside Docker, read-only PostgreSQL queries, filesystem evidence, Nginx settings and real HTTPS endpoints. Repairs stayed isolated and testable; business-dependent items received step-by-step guidance. These nine stories capture the engineering behind the simple phrase 'we fixed it'.

1. Turning the inbox into an engineering backlog

The first obstacle was not an exception: it was fragmented information. Retailer shipping questions, digital access problems, payment inconsistencies, PDF requests, administrator defects and release feedback arrived in overlapping email threads. It is easy to confuse an expectation with a delivered feature, a new defect with an old fix, or a test run with actual production behaviour. We therefore classified each item by business question, code path, environment, evidence, required change and the thread that deserved the response. 'Under investigation', 'fixed', 'verified in production' and 'awaiting business approval' became meaningful, separate states. Replies were generally prepared as drafts; we never equated drafting an email with sending it.

2. Production as evidence, not as a sandbox

Several investigations required carefully constrained diagnostics against the live Columbia Games environment. We distinguished repository source, the PHP files actually running inside Docker, the current database records and public HTTP responses. Hash comparisons established whether the application and administrator sources matched the expected release. Database inspection used read-only transactions, statement timeouts and narrow filters: a diagnostic command should not accidentally change customer records. One small health-check trap made the principle tangible: /health returned 404, while the actual /api/health endpoint returned HTTP 200. The wrong probe URL is not evidence that the application is down.

3. Retailer checkout: rules, not magic switches

Switching between retailer and default configuration initially looked like a simple administrative operation. Then we found a particularly dangerous context bug: after selecting retailer, navigating away and returning, the header silently displayed cg/default again. This was more than a cosmetic issue; it could lead an administrator to edit the wrong rule set. We corrected configuration-scope persistence and confirmed the interface behaviour. In parallel, we inspected retailer shipping rules and made a database backup before targeted configuration work. We carefully separated technical flexibility from the actual commercial policy. Whether all retailers should receive free shipping, and what country and tariff exceptions apply, must be determined by the business owner rather than silently assumed by the code. The related #351 task remains dependent on final tariff decisions and checkout UAT.

4. PayPal, country codes and checkout regressions

The payment pathway exposed multiple interacting assumptions: accepted checkout payment types, legacy value representations and the country codes passed to PayPal for shipping addresses. The focused hotfix mapped supported countries to canonical ISO alpha-2 codes and rejected invalid or unsupported values rather than quietly passing them downstream. Preserving the legacy CAN alias without corrupting the canonical alpha-2 table was a subtle additional constraint. The change proceeded as a separate PR with targeted regression coverage and live follow-up testing. A successful payment-path fix should handle both valid and invalid inputs predictably without introducing regressions elsewhere in checkout.

5. Digital library: entitlement, database and physical file

A product identifier in a database is not enough to establish that someone can download a purchased PDF. Entitlement, product mapping and the underlying file must all line up. For a HarnQuest 2026.3 support case, we identified two missing library entitlements. After a targeted preflight, the guarded transaction applied the repair and a read-back verified that the items appeared in the entitled library. For other products we compared SKU, downloadable_filename, storage paths and file signatures: confirming a PDF header or the correct Windows executable format provides stronger evidence than HTTP success alone. Harn maps, Kaldor and Melderyn sample documents, and the differences between legacy and newer asset locations all needed separate checks. We also audited PDF licence footers and watermark behaviour rather than assuming similarly named files use identical publishing paths.

6. /pix and media caching: refresh one image, not everything

Media operations became a real development task, not just another inspection. We added an admin-facing way to inspect and refresh the cache of an individual image, backed by scoped API endpoints, permission checks and regression tests. The surprising part was keeping cache generations coherent across canonical and www hostnames. Work covered Nginx header handling, a short five-minute browser caching policy, an idempotent normalizer and rollback considerations. The design avoids shaking the entire media delivery layer when only one image is stale. The related changes entered the release process in a dedicated PR, and we verified more than the presence of a new button.

7. PostgreSQL imports and access control

A related-products import failed under PostgreSQL because INSERT parameter types were ambiguous. Fixing the binding types was necessary, but a trustworthy repair also needed to demonstrate idempotence, role-based authorization and transactional rollback. We added isolated PostgreSQL regression checks and CI coverage for those properties. Other targeted production checks reviewed customer modifications, catalogue behaviour, discounts and administration boundaries. A matching source file is useful evidence of deployed code, but it does not by itself prove that every role can execute only its intended operations.

8. Billing, SMTP and email as a business interface

Some support work was not a conventional backend bug. For legacy billing and payment states we reconciled what was paid, what remained pending and what required follow-up, then prepared factual communication for the relevant stakeholder. On a separate path, we examined the public indicators of mail delivery configuration: MX, SPF, DMARC, only genuinely known DKIM selectors and SMTP constraints. Drafting an email, sending it, having it accepted by SMTP and proving final delivery are different events. We also treated a submitted FortiGuard category review as an external dependency: once a review is filed, a provider decision is pending; no code change can manufacture approval.

9. Release discipline: fixed, deployed, verified or waiting?

Much of the day was spent validating previously developed functionality in production rather than writing new features. Git hashes, container source, read-only database reads and HTTP smoke tests form distinct layers of evidence. A merge, a deployment, a healthy application and a successful end-to-end business flow are likewise different states. Instead of writing a generic 'everything is fixed' email, we explained per issue what changed, what had been tested and what still required configuration or business feedback. A missing tariff policy, external confirmation or reproducible case remains open. Dozens of separate conversations were ultimately consolidated into a tractable, evidence-driven support backlog.

Outcome

Tangible results included the fix for retailer configuration selection surviving navigation, a PayPal shipping-country mapping hotfix, scoped media-cache invalidation, corrected PostgreSQL parameter handling and regression tests for related-products imports, and a verified repair of missing HarnQuest library entitlements. We also ran targeted production QA for downloadable assets, PDF handling, admin access controls, catalogue behaviour, billing states and health probes. Email issues were grouped and response drafts prepared for the appropriate threads. Not every case was closed: retailer tariffs and final checkout UAT still depend on business choices, while the FortiGuard review awaits the external provider's decision.