Issue: TypeError thrown upon first instance of deserializing contents from cache for tables that are populated dynamically through data from CSV files.

More details:

• Some data around HoC activities are populated from csv files upon application start. These are then cached in rails memory cache for subsequent requests to avoid repeated deserialization from CSV files.
• The model for these entries are also dynamically generated on first load - which are defined in pegasus/data/static_models.rb
• The type error is thrown after fetching the cache entry and a deep copy of the object is made

Fix: Serializing the data to a JSON blob before storing it in cache.

Previous attempt at fixing this issue #54703. This earlier attempt was based on an incorrect theory that the issue is happening only during first read from a thread that had not hydrated the cache. But, I hadn't see the call stack then, and missed that the deep copy was when the error was raised. Additionally, now from the call stack we see that this problem occurs for both read and write operations.

Warning!!

We have entered Pixel Lock for Hour of Code!

Computer Science Education Week will be happening from Dec 4 - Dec 10. Alongside this event, we will
be launching our new Hour of Code activity. Please consider any risk introduced in this PR that
could affect Dance Lab, instructions, saving and logging student progress, caching, or anything
related to the Hour of Code activities, old or new. Even small changes, such as a different button
color, are considered significant during this time. If this change will affect the new Hour of Code
activity in any way, join the morning change review to get your changes approved prior to merging.
Reach out to the Student Labs team for more details!

Links

https://codedotorg.atlassian.net/browse/ACQ-918?atlOrigin=eyJpIjoiMWM3ZTUwZWQwYWMyNDIzNjk5ZjA5ZTNlMTBhNDQwNWMiLCJwIjoiaiJ9

Testing story

Validated the change by hitting the endpoint locally, which exercises this code path. http://localhost:3000/api/hour/begin_mc.png

Deployment strategy

Given this might be a risky change around HoC timeframe, I plan to keep the PR open and merge during the first week of January 2024.

Follow-up work

Validate that the errors are dropping after the change gets deployed. Will use the same JIRA ticket to track.

Privacy

N/A

Security

N/A

Caching

PR Checklist:

• Tests provide adequate coverage
• Privacy and Security impacts have been assessed
• Code is well-commented
• New features are translatable or updates will not break translations
• Relevant documentation has been added or updated
• User impact is well-understood and desirable
• Pull Request is labeled appropriately
• Follow-up work items (including potential tech debt) are tracked and linked