rockmigrations-lastrun log growing past 1.5 million entries

[FireWire]

The lastrun log file accumulates a lot of entries and is never automatically pruned/cleared. Production server has a ~50mb file with 1.5 million entries.

The log file contents are not written in a way that ProcessWire can parse.

Is this log file necessary for RM to function properly? The log entries are accumulating even when migrations are disabled.

[FireWire]

@bernhard Admittedly I just had to run some updates to the server firewall because we were getting hit with serious amounts of malicious traffic, so I don't think these may be numbers most RockMigrations users are going to see haha.

[bernhard]

Hey @FireWire thx for the report!

This was partly intended and partly not. The intentional part was that it SHOULD log something if migrations are triggered but disabled (to make it obvious if somebody expects migrations to do something and nothing happens).

What was also intentional is that the file does only reset when migrations actually run. The idea was to save disk read/write operations.

What was NOT intentional though is that this logging took place on every single request, which obviously means a small performance penalty on each request when using RockMigrations - even when it is disabled.

I just pushed a fix for this to v6.8.2 https://github.com/baumrock/RockMigrations/commit/429ce68f3418aeedee108d80949fc14a224561a5

Now the logging only happens when $config->debug is enabled. I also removed the log regarding MagicPages, which was logging on every single request, adding an additional file write on every single request 😮 Thank you for making me aware of that!

[FireWire]

@bernhard Excellent! It took 6 months and a bot attack to get to that number. We were getting many requests per second so this is probably not something many users experience. I'll call it "accelerated testing" 🤣

Thanks for the fix!

[bernhard]

Either way it should not log something on each request. The goal is that RockMigrations does not slow down the site and only does something when it really needs to do something. This was obviously not the case here even though a single fileputcontents() might not be a noticeable penalty, but still...