Fix concurrent stat insertion duplicate key errors log message

[undaunt]

⚠️ Please Note: We do not accept all types of pull requests, and we want to ensure we don't waste your time. Before submitting, make sure you have read our pull request guidelines: Pull Request Rules

📋 Overview

• What problem does this pull request address?

  Users with many monitors (200+) frequently encounter database duplicate key errors when multiple monitors attempt to insert statistics simultaneously. This manifests as Error: Duplicate entry '1-1703123456' for key 'monitor_id' and occurs because the current implementation uses RedBean's R.store() which performs separate SELECT and INSERT/UPDATE operations, creating race conditions when multiple monitors update statistics for the same time period.

• What features or functionality does this pull request introduce or enhance?

  Implements atomic upsert operations for stat table insertions using database-specific SQL syntax (SQLite ON CONFLICT and MariaDB ON DUPLICATE KEY UPDATE). Also resolves related circular dependency and schema naming issues that prevent the upsert functionality from working correctly.

🔄 Changes

🛠️ Type of change

• 🐛 Bugfix (a non-breaking change that resolves an issue)

🔗 Related Issues

• Fixes Receiving a trace error: insert into 'stat_hourly' - Duplicate entry '43-1731949200' for key 'stat_hourly_monitor_id_timestamp_unique' #5357

📄 Checklist

• 🔍 My code adheres to the style guidelines of this project.
• ✅ I ran ESLint and other code linters for modified files.
• 🛠️ I have reviewed and tested my code.
• 📝 I have commented my code, especially in hard-to-understand areas (e.g., using JSDoc for methods).
• ⚠️ My changes generate no new warnings.
• 🔒 I have considered potential security impacts and mitigated risks.
• 📚 I have read and understood the Pull Request guidelines.

ℹ️ Additional Context

Key Considerations:

• Design decisions – Used database-specific atomic upsert operations rather than application-level locking to ensure maximum performance and reliability. Falls back to original R.store() behavior if upsert fails, ensuring no data loss.

• Alternative solutions – Considered application-level mutex/locking but atomic database operations are more efficient and reliable for this use case.

• Dependencies – Required fixing circular dependency between database.js and uptime-calculator.js, and ensuring Database.dbConfig is properly initialized in all code paths.

Technical Details:

The fix addresses several interconnected issues:

1. Race conditions: Multiple monitors hitting the same stat table rows simultaneously
2. Circular dependency: database.js imports UptimeCalculator, but UptimeCalculator needs Database.dbConfig
3. Missing config initialization: Database.dbConfig wasn't being set when db-config.json is missing
4. Schema mismatch: RedBean uses camelCase (pingMin) but the actual database schema uses snake_case (ping_min)

Testing performed:

• High-frequency monitor updates (every 10 seconds)
• Concurrent database operations with 200+ monitors
• Both SQLite and MariaDB backends
• Migration scenarios and fresh installations

Backward compatibility: No breaking changes. If upsert fails for any reason, gracefully falls back to the original R.store() approach with appropriate logging.

[CommanderStorm]

I don't like the solution here.. feels like a horrible hack.
@louislam do you think adding upserts to https://github.com/louislam/redbean-node would be hard? I have not looked at its internals..

[louislam]

@CommanderStorm I afraid that could be hard too, because RedBeanNode underlying is also not using raw sql. It is using knex(...).insert({ ... });.

But before that, I would like to have a simple reproduce steps (or simple PoC), because I am still not fully understand.

In Uptime Kuma, getDailyStatBean is written in singleton pattern, it should always return the same object. In RedBean, R.store() will lock it before insert/update. Insert at the same time doesn't seem possible to happen.

Uptime Kuma's getDailyStatBean():

    async getDailyStatBean(timestamp) {
        if (this.lastDailyStatBean && this.lastDailyStatBean.timestamp === timestamp) {
            return this.lastDailyStatBean;
        }

RedBeanNode's R.store():

    async store(bean: Bean, changedFieldsOnly = true) {
        await bean.beanMeta.lock.acquireAsync();

[louislam]

Just checked knex's doc, it has a function for upsert:

https://knexjs.org/guide/query-builder.html#merge

[Ionys320]

Hi @undaunt! Would you mind implementing the knew upsert feature as mentioned by @louislam?