View Issue Details

IDProjectCategoryView StatusLast Update
5256Composrcorepublic2023-01-24 20:55
ReporterPDStig Assigned ToGuest  
PrioritynormalSeverityfeature 
Status newResolutionopen 
Summary5256: 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
Attach Tags
Attached Files
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)   
Time estimation (hours)4
Sponsorship open

Sponsor

Date Added Member Amount Sponsored

Activities

Chris Graham

2023-01-24 20:55

administrator   ~7885

Last edited: 2023-01-24 20:55

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.

Add Note

View Status
Note
Upload Files
Maximum size: 32,768 KiB

Attach files by dragging & dropping, selecting or pasting them.
You are not logged in You are not logged in. This means you will not get any e-mail notifications. And if you reply, we will not know for sure you are the original poster of the issue.

Issue History

Date Modified Username Field Change
2023-01-24 16:38 PDStig New Issue
2023-01-24 16:38 PDStig File Added: diff.diff
2023-01-24 16:39 PDStig 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
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
2024-03-26 00:58 PDStig Tag Renamed Roadmap: v12 => Roadmap: Over the horizon