Hi everyone,
Here’s a brief summary of our weekly *Apache ResilientDB (Incubating)*
community
meeting held on *December 1, 2025* for those who couldn’t attend:
Attendees: Aahan Rathod, Bismanpal Anand, Devang Borkar, Harish
Krishnakumar, Junchao Chen, Mohammad Sadoghi, Shaokang Xie, Zehong Ruan
*Brief Summary:*
The team discussed various ongoing projects including request tracing
implementation, documentation automation, and UI component development.
They addressed technical issues related to server downtime, data
consistency problems, and API call concerns. The team also covered website
updates, storage instance management, and discussed plans for future
development including file sharing capabilities and monorepo restructuring.
Action Items:
-
Fix publication display issue on mobile for Apache website, Update
website with new flyer and update the roadmap timelines.
-
Implement missing recovery functionality for checkpoint data
synchronization between replicas, fix production server issues and bring
database back to a consistent state
-
Transform ResCanvas into UI component toolkit and place under
ecosystem/drawing library
-
Retire old Explorer and fix issues with ResLens Explorer once production
is restored.
*1. Project Progress and Deployment Updates*
The team discussed progress on various projects, including Harish's work on
implementing request tracing for the ResAI hub and Bismanpal's efforts to
automate documentation updates for ResAI. They noted that cleanup tasks for
the last release were nearly complete, with Bismanpal planning to highlight
deprecated projects more clearly. Mohammad mentioned that deployment
discussions might increase this week as teams wrap up their projects, and
the team agreed to monitor progress reports for potential project
graduations.
*2. GraphQL API Deprecation Issue*
The team discussed an issue with the GraphQL interface in ResilientDB,
where the deprecated 'getAll' API call was causing problems. Harish
identified that the Python and Node cache applications were the only
services using this API, and he had instructed Henry to stop using it.
Despite restarting the server multiple times, the issue persisted,
resulting in a 502 Gateway error on the production instance. Harish agreed
to run the restart scripts while Junchao monitored the logs to identify the
root cause.
*3. **Server Overload and Deployment Issues*
The team discussed issues with data loss and server downtime when
triggering the 'getAll' function. Junchao explained that the problem occurs
when the server is overloaded with large data values, leading to a
consensus stack and data loss. Harish inquired about the deployment process
for the production instance, and Junchao guided him to the script folder
where deployments can be run by filling in the IP addresses. They clarified
that the ResilientDB changes are not currently reflected in the production
binary, and Harish decided to use the dev instance for those changes
instead.
*4. **Data Recovery and Consensus Issues*
The team discussed issues with data inconsistency and recovery mechanisms
in their system. Junchao explained that the problem occurred when some
replicas could not handle large data loads during consensus, leading to
inconsistent states. Mohammad suggested implementing view change recovery
to address this issue. The team agreed to add two crucial data recovery
features and to remove a problematic API. Harish mentioned that the
Explorer ResilientDB issue was due to the production instance being down.
Ending Note:
The meeting concluded with a clear focus on stabilizing production systems,
improving data consistency, and advancing key development initiatives. The
team reaffirmed its commitment to addressing recovery and consensus issues,
finalizing documentation automation, and restructuring components under the
monorepo for better maintainability. With coordinated efforts across
deployment, UI development, and infrastructure reliability, ResilientDB
(Incubating) continues to strengthen its technical foundation while
preparing for upcoming releases and long-term project scalability.
-
Best,
*Bismanpal Singh Anand*PPMC, ResilientDB (Incubating)
