Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Tracking Down Keely's Guest Page: A Multi-Layer Content Discovery Workflow

During a recent development session, we needed to locate and assess the status of a guest contributor page for Keely across our content infrastructure. What seemed like a straightforward content lookup turned into a valuable case study in systematic debugging across our distributed storage and handoff management systems. This post documents the investigation methodology and the technical layers we queried to understand the current state of this asset.

The Initial Request and Search Strategy

When tasked with determining the status of Keely's guest page, we faced a fundamental challenge: content for tech.queenofsandiego.com lives across multiple systems with different purposes and update cadences. Rather than guessing where to look, we implemented a systematic search pattern that mirrors how our infrastructure is actually organized:

  • Handoff project management system — where content assignments and collaboration tasks are tracked
  • Primary website repository — the canonical source for published content
  • S3 storage buckets — where static assets and content staging occurs
  • Local development directories — the g/ folder structure used in our development environment
  • S3 metadata layer — object tags and metadata that provide context about content state

This layered approach is intentional. It reflects the reality that content may exist in multiple states: assigned but not started, in progress, staged for review, published to production, or archived.

Technical Details of the Investigation

Step 1: Active Handoff Projects Audit

We began by listing active handoff projects to understand whether Keely's guest page was formally tracked as a current assignment. The handoff system serves as our source of truth for in-flight work items and their ownership.

# Command structure used to enumerate active handoff projects
# This queries our project management layer to identify all active assignments
list active handoff projects

This step serves a critical function: it tells us whether the work is even on the books. If a page assignment doesn't exist in the handoff system, it's either completed, cancelled, or never formally initiated.

Step 2: Handoff System Search for Keely

With active projects listed, we then performed a targeted search within the handoff system specifically for "Keely":

# Search within handoff project management for any references to Keely
search for Keely in handoffs

This narrows the scope significantly. The handoff system indexes by contributor name, project status, and content type. A match here would indicate active collaboration; no match might mean the work is completed or the contributor details are stored differently.

Step 3: QOS Site Content Search

Next, we queried the tech.queenofsandiego.com site repository directly:

# Search the published QOS site for any existing Keely-related content
search QOS site for Keely

This search targets our production content repository. QOS site content is typically stored in a structured directory hierarchy (e.g., /content/guest-contributors/, /content/authors/, or similar). A successful match would indicate that a page already exists and is discoverable through the site's content search index.

Step 4: S3 Storage Check

Since guest pages are often stored as static assets before being integrated into the site, we checked our S3 bucket structure:

# Check S3 for Keely guest page artifacts
check S3 for Keely guest page

Our S3 architecture typically organizes guest content under a predictable path structure. For a guest contributor page, we'd expect paths like:

  • s3://qos-content-staging/guest-pages/keely/
  • s3://qos-static-assets/contributors/keely/
  • s3://qos-archives/guest-content/

The S3 check is important because it reveals content that may be staged but not yet published, or archived after removal from the live site.

Step 5: Local Development Environment Search

Our development workflow uses a local g/ folder (typically at ~/projects/qos/g/ or similar) as a working directory for guest content:

# Check local development folder structure for Keely-related files
check local g/ folder for Keely

This directory would contain work-in-progress files, drafts, or files being prepared for upload. The presence of files here indicates active development work not yet promoted to production systems.

Step 6: S3 Metadata Layer Investigation

Finally, we examined S3 object metadata and tags associated with any Keely-related content:

# Check S3 metadata for Keely page (tags, custom attributes, timestamps)
check S3 metadata for Keely page

S3 objects in our infrastructure are typically tagged with metadata including:

  • content-status — values like "draft", "staging", "published", "archived"
  • contributor-name — indexed for attribution and tracking
  • last-modified — timestamp of most recent change
  • cloudfront-invalidation-pending — flag indicating CDN cache refresh is needed
  • review-status — internal workflow stage indicator

Metadata tags are queryable and provide machine-readable insight into content state without requiring us to inspect object content directly.

Why This Multi-Layer Approach Matters

Our infrastructure benefits from this systematic search pattern because:

  • Separation of concerns — Handoff system tracks assignments independent of actual content location, allowing for flexibility in where content lives
  • State visibility — By checking multiple layers, we can detect content stuck in intermediate states (e.g., uploaded to S3 but not yet published to the live site)
  • Debugging efficiency — If content is missing from the site but exists in S3, we know to investigate CloudFront distribution configuration or Route53 routing rather than searching for missing files
  • Audit trail — Metadata in S3 provides a record of when content was last touched and its current workflow status

Infrastructure Implications

This investigation pattern relies on specific infrastructure components:

  • S3 buckets for content staging and storage with versioning enabled
  • CloudFront distributions (with specific distribution IDs tied to different content types) for CDN serving
  • Route53 DNS records pointing to CloudFront origins, allowing dynamic traffic routing
  • Local development environment with synchronized folders that mirror production S3 structure
  • Handoff project management system serving as the authoritative source for work item state

Understanding these layers helps engineers quickly locate content and diagnose why it may not be appearing on the live site even when files exist somewhere in the system.

Next Steps and Ongoing Monitoring

Based on the investigation results, the next phase would involve:

  • If content exists but isn't visible: Check CloudFront cache invalidation status and confirm Route53 routing rules
  • If content is only in local or staging: