View Issue Details

IDProjectCategoryView StatusLast Update
0005256Composrcorepublic2023-01-24 20:55
ReporterPatrick SchmalstigAssigned To 
SeverityFeature-request 
Status non-assignedResolutionopen 
Product Version 
Fixed in Version 
Summary0005256: readonly_db massively maintenance code broken: re-add support for this
DescriptionCurrently (especially in the upcoming v11), the Composr site crashes when a DB loses write access. It is not feasible for us to fix that at this time given the complexity. Therefore, this has been knocked back to feature-request status.

readonly_db has been marked unsupported, not even for bugs. The maintenance sheet will need updating once we support this again.
Additional InformationAttached is the start of me working on this issue. However, I stopped when I realized this issue extends far beyond core Composr even for a simple page load. There are queries across different hooks, such as the blocks, which will also break the site when DB loses write access.
TagsRoadmap: Over the horizon
Time estimation (hours)4
Sponsorship open

Activities

Patrick Schmalstig

2023-01-24 16:38

administrator  

diff.diff (2,574 bytes)
diff --git a/sources/caches2.php b/sources/caches2.php
index 4de6ec159a..50572e15fd 100644
--- a/sources/caches2.php
+++ b/sources/caches2.php
@@ -175,7 +175,11 @@ function set_cache_entry(string $codename, int $ttl, string $cache_identifier, $
                 'the_theme' => $theme,
                 'cached_for' => $codename,
                 'identifier' => md5($cache_identifier),
-            ]
+            ],
+            '',
+            null,
+            0,
+            true // Suppress errors in case we lost DB write access
         );
         $GLOBALS['SITE_DB']->query_insert(
             'cache',
diff --git a/sources/failure.php b/sources/failure.php
index 00a9948969..c160095f27 100644
--- a/sources/failure.php
+++ b/sources/failure.php
@@ -524,7 +524,7 @@ function _generic_exit($text, string $template, ?bool $support_match_key_message
     if ((get_forum_type() == 'cns') && (get_db_type() != 'xml'/*Too intensive*/) && (isset($GLOBALS['FORUM_DRIVER']))) {
         require_code('cns_groups');
         $restrict_answer = cns_get_best_group_property($GLOBALS['FORUM_DRIVER']->get_members_groups(get_member()), 'flood_control_submit_secs');
-        $GLOBALS['FORUM_DB']->query_update('f_members', ['m_last_submit_time' => time() - $restrict_answer - 1], ['id' => get_member()], '', 1);
+        $GLOBALS['FORUM_DB']->query_update('f_members', ['m_last_submit_time' => time() - $restrict_answer - 1], ['id' => get_member()], '', 1, 0, false, true); // Suppress errors in case we lost database write access
     }
 
     if ($title === null) {
diff --git a/sources/global3.php b/sources/global3.php
index 735f042bee..586eb06df1 100644
--- a/sources/global3.php
+++ b/sources/global3.php
@@ -3235,7 +3235,7 @@ function get_num_users_site() : int
             $PEAK_USERS_WEEK_CACHE = $NUM_USERS_SITE_CACHE;
 
             // But also delete anything else in the last 7 days that was less than the new weekly peak record, to keep the stats clean (we only want 7 day peaks to be stored)
-            $GLOBALS['SITE_DB']->query('DELETE FROM ' . get_table_prefix() . 'usersonline_track WHERE date_and_time>' . strval(time() - 60 * 60 * 24 * 7) . ' AND peak<=' . $PEAK_USERS_WEEK_CACHE);
+            $GLOBALS['SITE_DB']->query('DELETE FROM ' . get_table_prefix() . 'usersonline_track WHERE date_and_time>' . strval(time() - 60 * 60 * 24 * 7) . ' AND peak<=' . $PEAK_USERS_WEEK_CACHE, 1000, 0, true); // Errors suppressed in case DB write access broken
 
             // Set record for week
             set_value('user_peak_week', $PEAK_USERS_WEEK_CACHE);
diff.diff (2,574 bytes)

Chris Graham

2023-01-24 20:55

administrator   ~0007885

Last edited: 2023-01-24 20:55

View 2 revisions

We discussed this, and the main issue is that while we could error-suppress our way through all the failing write queries, it's just kind of sweeping things under the rug, causing potential future bugs where important queries are invisibly failing.
A better approach is to change it so that an error handling option is passed to the query functions which allows normal error handling, no error handling, or error logging.
We would have to review all existing use of the option to use the correct flag.
We would then have to reimplement working readonly_db support.

Issue History

Date Modified Username Field Change
2023-01-24 16:38 Patrick Schmalstig New Issue
2023-01-24 16:38 Patrick Schmalstig File Added: diff.diff
2023-01-24 16:39 Patrick Schmalstig Tag Attached: Roadmap: v12
2023-01-24 20:52 Chris Graham Summary readonly_db massively broken: re-add support for this => readonly_db massively maintenance code broken: re-add support for this
2023-01-24 20:52 Chris Graham Description Updated View Revisions
2023-01-24 20:53 Chris Graham Time estimation (hours) => 4
2023-01-24 20:55 Chris Graham Note Added: 0007885
2023-01-24 20:55 Chris Graham Note Edited: 0007885 View Revisions
2024-03-26 00:58 Patrick Schmalstig Tag Renamed Roadmap: v12 => Roadmap: Over the horizon