NexusMods

Hi, we are seeing issues with the viewupdates task in the system logs:

ArgumentCountError: Wrong parameter count for Redis::zRem() (0)
#0 /var/www/html/system/Redis/Redis.php(250): Redis->zRem('topic_views')
#1 /var/www/html/applications/core/tasks/viewupdates.php(86): IPS\_Redis->__call('zRem', Array)
#2 /var/www/html/system/Task/Task.php(375): IPS\core\tasks\_viewupdates->IPS\core\tasks\{closure}()
#3 /var/www/html/applications/core/tasks/viewupdates.php(38): IPS\_Task->runUntilTimeout(Object(Closure))
#4 /var/www/html/system/Task/Task.php(274): IPS\core\tasks\_viewupdates->execute()
#5 /var/www/html/system/Task/Task.php(237): IPS\_Task->run()
#6 /var/www/html/applications/core/interface/task/task.php(72): IPS\_Task->runAndLog()
#7 {main}

It seems adding an !empty check on the $redis array in viewupdates.php fixes the error:

 
if( \is_array( $redis ) && !empty($redis) ) { foreach ( $redis as $data => $count )  

Hi there,

We unfortunately have come across some abuse of the private message / conversation feature.

What happens:
Users can message each other, then block the others / themselves from a conversation. As the conversation then has no participants, it's deleted and we have no trace, making it difficult to moderate.

Expected behaviour:
When there are only two participants, users shouldn't be able to remove the other member (to cause the deletion), or there needs to be some way of verifying that the PM did exist as a forum admin.
 
How to reproduce:

Here is the steps to reproduce from our team:
 
Log into AccountA - send a PM to AccountB Within the PM UI, select AccountB from the list of participants and select "Remove from conversation". Delete the message from your inbox as AccountA. Log into AccountB - see that this PM "never existed" but you still have an email confirming it was sent to you.  
The class / method in question is
Messenger\Conversation::deauthorize


If you need any more information, please let us know.

Hi there,

We unfortunately have come across some abuse of the private message / conversation feature.

What happens:
Users can message each other, then block the others / themselves from a conversation. As the conversation then has no participants, it's deleted and we have no trace, making it difficult to moderate.

Expected behaviour:
When there are only two participants, users shouldn't be able to remove the other member (to cause the deletion), or there needs to be some way of verifying that the PM did exist as a forum admin.
 
How to reproduce:

Here is the steps to reproduce from our team:
 
Log into AccountA - send a PM to AccountB Within the PM UI, select AccountB from the list of participants and select "Remove from conversation". Delete the message from your inbox as AccountA. Log into AccountB - see that this PM "never existed" but you still have an email confirming it was sent to you.  
The class / method in question is
Messenger\Conversation::deauthorize


If you need any more information, please let us know.

Hi there,

We unfortunately have come across some abuse of the private message / conversation feature.

What happens:
Users can message each other, then block the others / themselves from a conversation. As the conversation then has no participants, it's deleted and we have no trace, making it difficult to moderate.

Expected behaviour:
When there are only two participants, users shouldn't be able to remove the other member (to cause the deletion), or there needs to be some way of verifying that the PM did exist as a forum admin.
 
How to reproduce:

Here is the steps to reproduce from our team:
 
Log into AccountA - send a PM to AccountB Within the PM UI, select AccountB from the list of participants and select "Remove from conversation". Delete the message from your inbox as AccountA. Log into AccountB - see that this PM "never existed" but you still have an email confirming it was sent to you.  
The class / method in question is
Messenger\Conversation::deauthorize


If you need any more information, please let us know.

Hi,

We've been having issues every 6 hours when the badge status cache expires and they regenerate. This causes our (rather large) DB to hit 100% CPU and the forums become unresponsive.

Looking into this, the issue is that multiple threads will try to get the badge stats at once when they expire: \IPS\core\Achievements\_Badge::getBadgeStats()

We have approximately 40 concurrent requests trying to regenerate these stats every 6 hours.

As a work around, we are temporarily updating the stats expiration while we re-generate the statistics, this results in it only running once per 6 hours (instead of 40 times)

 
if( !isset( $stats['expiration'] ) OR time() > $stats['expiration'] OR !isset( $stats['badgeCount'][ $this->id ] ) ) { // Write the old stats back to the store while we regenerate them $stats['expiration'] = time() + 60; \IPS\Data\Store::i()->badgeStats = json_encode( $stats ); $stats = NULL; }  

Hi,

We've been having issues every 6 hours when the badge status cache expires and they regenerate. This causes our (rather large) DB to hit 100% CPU and the forums become unresponsive.

Looking into this, the issue is that multiple threads will try to get the badge stats at once when they expire: \IPS\core\Achievements\_Badge::getBadgeStats()

We have approximately 40 concurrent requests trying to regenerate these stats every 6 hours.

As a work around, we are temporarily updating the stats expiration while we re-generate the statistics, this results in it only running once per 6 hours (instead of 40 times)

 
if( !isset( $stats['expiration'] ) OR time() > $stats['expiration'] OR !isset( $stats['badgeCount'][ $this->id ] ) ) { // Write the old stats back to the store while we regenerate them $stats['expiration'] = time() + 60; \IPS\Data\Store::i()->badgeStats = json_encode( $stats ); $stats = NULL; }  

Sharing this in case it helps others, or can be merged upstream.
While migrating a large forum we were encountering some poor performance that was narrowed down to DB.preparedQuery. Changing the substitution approach yielded a 10x speedup.
Current implementation does:
/* For NULL values, you can't bind, so we adjust the query to actually pass a NULL value */ $pos = 0; for ( $j=0; $j<$i; $j++ ) { $pos = mb_strpos( $query, '?', $pos ) + 1; } $query = mb_substr( $query, 0, $pos - 1 ) . 'NULL' . mb_substr( $query, $pos ); We replaced this with:
// Replace the i'th '?' character with 'NULL'. $found = preg_match_all('/'.preg_quote('?').'/', $query, $matches, PREG_OFFSET_CAPTURE); if (false !== $found && $found >= $i) { $query = substr_replace($query, 'NULL', $matches[0][$i - 1][1], 1); } If there is a better place to raise this for upstream then please let me know.

try that first of all, and then let us know if you are still seeing issues