in issue 2551228 I noted:

   It addresses the need to  compare values of interesting properties in the reactor
   rather than checking to see if the properties we are interested in are "in" oldvalues.
   Currently:

      "interesting_prop" in oldvalues

   is always true even if interesting_prop wasn't changed in this
   transaction.

   The spec (references.txt) for reactors says olddata (usually named
   oldvalues in actual code) says: 

     For a ``set()`` operation, ``olddata`` contains the names and previous
     values of properties that were changed.

   oldvalues has the previous value for *all* properties of the object, not
   just changed properties. This differs from an auditor where "'propname' in
   newdata" is a useful statement. I'll open a discussion on the dev list. If
   this is a mistake (it has been this way since version 0.5.0 AFAICT) I'll open
   a ticket to fix it in the core and reference it in this issue.

The discussion starting with: https://sourceforge.net/p/roundup/mailman/roundup-
users/thread/CANfx4mvKAh4Qgju8-
AgJ8Y0ZRAomeydgsWdTYXL5iCM6CZnJ7A%40mail.gmail.com/#msg59407652

leads me to think it is a bug (Ralf noted the issue a while ago, but wasn't sure if
it was intentional' he also compares values to see if a value changed).

If you use oldvalues.get('propname') you get None returned if the keyword is missing.
If you use oldvalues['propname'] you get a KeyError raised.

Ralf uses .get() in his reactors.

So three options to fix this:

  1) update the docs to indicate the current code
  2) change the code to only include changed database items and everybody needs
     to audit their reactors.
  3) provide two paths with/without unchanged props and a switch (in
     config.ini or interfaces.py) to remove unchanged props (default is
     to include them).

1 is easiest, but I really want "'unchanged prop' in oldvalues" to
work because it reduces cognitive load by matching auditors and
eliminates unneeded database accesses to compare values.

2 is preferred but makes upgrading more difficult.

3 adds another switch that most people won't know about, clutters
config.ini and increases testing burden.

Ralf voted for 2 with docs in upgrading.txt. He expects his reactors all use oldvalues
and a grep should allow him to identify cases where there is a problem.

Unless other people chime in, I'll start work on 2 tomorrow.

The work includes:

  code changes to strip unchanged items

  check packaged reactors do not break with this change

  upgrading.txt doc entry at 'required' level

  doc checks for any reactors to make sure they use 'propname' in oldvalues
      or "o_val = oldvalues.get(); if o_val is None: return" etc. for short circuiting.


  check wiki for problems and update pages with a notice about this change.

I think that's everything to cover.