SQLite Memory Leak

Our servers were blowing up with OOM.

The culprit was with some of the Activity API database queries. Our SQLite library by default caches prepared statements for the whole lifespan of the process — most of the time this is exactly what you'd want, because you achieve the dynamism with the queries by using binding parameters. Activity API though was using some dynamic queries that were not reused, so each subsequent call to the Activity API was generating prepared statements that were never reused again, and that was filling up the cache without limits.

For now we just disabled the query cache for those activity/feed related queries.

Private Documents

I finally implemented a working visibility tracking for blobs. So now, I'm able to accurately track whether a blob is public, and propagate the public visibility state to all the downstream blobs, regardless of the order in which we receive those blobs.

This was the most complicated part of the project probably.

Next Week

The plan for the next week is to keep working on private document. Integrate the blob visibility into Bitswap and RBSR to make sure we don't leak any private blobs without authorization.

In addition to that — implementing the authentication protocol so peers could introduce their account IDs to prove access to private data.