Habitica: [API v3] Disable parts of Cron for migration day

[paglias]

[Alys]

My plans (comments, suggestions, changes welcome):

• [x] Look through cron code in detail to see if anything else should be added below.
• [x] Create a permanent "safe mode" flag for cron so that the after-maintenance behaviour can be turned on and off easily.
  
  
  
  • [x] Adjust config.json to contain CRON_SAFE_MODE environment variable, set to the string "false" normally.
  
  
  • [x] Adjust api-v3 test server to contain CRON_SAFE_MODE environment variable, set to the string "false" normally, but "true" for using safe mode.
  
  
  • EDIT: NO POINT DOING THIS: Adjust production server to contain CRON_SAFE_MODE environment variable, set to "false".
  
  
  • [x] Adjust Heroku test servers to contain CRON_SAFE_MODE environment variable, set to "false".
  
  
• Safe mode makes these changes to cron:
  
  
  
  • [x] Incomplete Dailies do not cause player damage.
  
  
  • [x] Incomplete Dailies do not cause damage to the party from the quest boss.
  
  
  • [x] The attack message in party chat is different (bolding shows the different part): "PlayerName attacks BossName for 123 damage. BossName did not attack the party because it was asleep while maintenance was happening." (NB: that message is currently not translated so no need to get this string into Transifex in advance.)
  
  
  • EDIT: DID NOT DO because links don't work inside the standard formatting for system messages, and it's not important enough to make a change for that: Add a URL to the new message to point to a blog post or something explaining the maintenance.
  
  
  • [x] Incomplete Dailies do not have their streaks reset.
  
  
  • [x] Incomplete Dailies do not have their colour/value changed (they do not move towards red).
  
  
  • [x] Incomplete Dailies do not reduce the overnight gain of mana.
  
  
  • [x] Player gets a Perfect Day even if some Dailies were incomplete.
  
  
  • [x] Incomplete To-Dos and singleton Habits change colour as normal.
  
  
  • EDIT: DECIDED TO NOT DO THIS (too complex, not really important): ??? Buffs do not expire? Nice for those players who would otherwise have missed the buffs, but could lead to over-buffing for some players. If we do this, include players who are resting in the inn. If we do this, how do we deal with the Perfect Day buff - add it on top of the existing buffs? Code will be simpler if we allow all buffs to expire.
  
  
  • EDIT: NOT RELEVANT (because above point isn't done): ??? If buffs don't expire, do we make an exception that causes Transformation Item buffs to expire as normal, since some players might not like being transformed for two days and might not know how to cancel the buff?
  
  
  • [x] A subscription that is due to terminate is not terminated. This would prevent complaints about not being able to get the subscription benefits for the final day of the subscription. Not so important for a maintenance window of less than a day, but would be important if there's ever a longer one in future (or if we use maintenance mode after a long period of inadvertent downtime). NB: The subscription would then terminate on the next cron.
  
  
  • [x] Set ALittleYellowSpider's subscription end date to be in the past. Do NOT cron normally.
  
  
  • [x] Cron in safe mode and confirm the subscription remains.
  
  
  • [x] Cron in normal mode and confirm the subscription ends.
  
  
  • EDIT: DO NOT DO THIS: Old completed To-Dos and old history entries that would be purged are not purged? Avoids complaints about old data being removed before the user had time to export it. NB: They would be purged on the next cron. I'm not sure if I really care about this point; I'm just being thorough. Although if there were a lot more people than usual logging in around the same time (likely since they've been locked out for hours), it might be helpful to avoid the extra processing that would come from purging history entries? @paglias ?
  
  
  • EDIT: NOTHING TO BE DONE: Analytics: Do we want to record anything special here? @SabreCat ?
  
  
• EDIT: DECIDED NOT TO (the boss damage message in party chat will cover this for some players and other can read the blog post): ??? Safe mode adds message to user's tasks page to explain why they didn't lose any health?
• [ ] Write and test automatic tests for safe mode: https://github.com/HabitRPG/habitrpg/issues/7464
• [x] Testing:
  
  
  
  • [x] Manual testing locally of normal cron mode after the safe-mode code is in place.
  
  
  • [x] Manual testing locally of this safe mode.
  
  
  • [x] Manual testing locally of quest damage and message with this safe mode (requires quest bugs to be fixed first).
  
  
  • [x] Manual testing on semi-prod server of normal cron mode after the safe-mode code is in place.
  
  
  • [x] Manual testing on semi-prod server of this safe mode.
  
  
  • [x] Manual testing on semi-prod server of quest damage and message with this safe mode.
  
  
• [x] When maintenance window starts, set production server CRON_SAFE_MODE environment variable to "true".
• [x] The instant the maintenance window is over, cron to ensure safe mode is working.
• [ ] 48 hours after maintenance window ends, set production server CRON_SAFE_MODE environment variable to "false".

[paglias]

I think we don't care about purging old todos and history compression happening a day later and it shouldn't cause perf problems

[SabreCat]

Analytics shouldn't need anything unusual. We do need to make sure we still send the cron event, because that's the most reliable indicator we have of a user checking in on a given day.

[Alys]

CRON_SAFE_MODE is set to true on v3.habitica.com now.

[ghost]

Sorry for spamming, but I couldn't help mentioning that a new system message is really great!

The SnackLess Monster did not attack the party because it was asleep while maintenance was happening.

[Alys]

Reopening because I still need to finish the automatic tests, and also a few things that we can't do until later.

@paglias If you want the title changed so that it doesn't fall into your API v3 filter, that's fine with me!

[paglias]

@Alys sorry, I should have asked! It's fine to keep it under API v3

[SabreCat]

Based on the above conversation, I'm moving the remainder of this ticket to "post-v3" -- feel free to fix if that's in error!

[Alys]

I've moved it back. :) Most of the "later" actions are for later today/tomorrow. Add blog post URL when it's available, update environment variables.