The context
Creators Pro coordinates creators and the teams managing their content production. The team assigns tasks and handles editing, approval and publishing; creators receive requests in the iOS app and upload photos and videos.
I worked on building and evolving the upload flow: media selection, native formats and iCloud assets, progress reporting and background uploads. Over time, the system moved from Google Drive and Airtable integrations to transfers to Google Cloud Storage using signed URLs.
The problem
File transfer and the application status update happened at different times. After a file reached storage, the backend needed to process a Pub/Sub event to activate the content in the database.
In some cases the file was present, but that update did not complete. I worked on diagnosis, the changes, behaviour verification and content recovery, including work in pair programming.
The diagnosis
I improved the messages sent to Sentry and analysed logs to trace the events.
The issue involved environments running different versions of the code: local processes could receive messages from the same subscription used by the intended system. Processing could therefore finish without activating the content in the correct database.
The changes addressed subscription configuration for each environment and error handling during processing. One important part was allowing operational errors to reach the listener, so that failed processing could request another attempt.
From manual recovery to debugging APIs
Initially, I manually recovered content that had remained inactive. As the issue recurred and cases accumulated, I introduced dedicated APIs to inspect and correct statuses in a controlled way.
The tools allowed me to find cases by status and date range, select the IDs to process and limit the number of records updated in a request. The summary distinguished updated content from records that were already completed, missing or ineligible.
I later added an optional check for the original file in the bucket before activation. With the check enabled, missing files and failed checks were skipped and reported in the response.
I personally used these APIs to recover content and improved them on several occasions. They were operational tools I used while maintaining the system.
The result
I recovered the content that had remained inactive and built a reusable procedure for subsequent cases. Information collected in Sentry and logs supported the diagnosis; the APIs gave structure to the recovery work I had been doing manually.
Technical details
The diagram shows the logical stages of this case and the operational recovery path.
- Selection and preparation on iOS
- File in storage
- Pub/Sub event
- Backend processing
- Database status updated
Inactive record → inspection and recovery through debugging APIs → controlled status update.
Acknowledging events
The listener acknowledges the message after the handler returns. Operational errors must propagate to the listener to allow a negative acknowledgement and another attempt. Subscription configuration determines which events each environment receives.
Recovery scope
The APIs worked on explicit IDs, up to 100 per request, and checked the caller’s organisation and record eligibility. Updates applied to source media that had not been deleted and excluded records that were already completed.
Checking the file
The optional bucket check verified that the original file existed. Content validity and any Google Drive copy were separate checks. This tool handled cases left blocked, while changes to configuration and event processing addressed the cause.