[Mailman-Developers] When a user is deleted, is the uid record intentionally not deleted?

[Barry Warsaw]

On Feb 05, 2015, at 10:53 AM, Andrew Stuart wrote:

>I notice that when a user is deleted, the uid record remains.
>
>Is this because there is a bug in which the uid should be deleted but is not?
>
>or is this intentional behaviour to prevent the uid from being recreated as a
>duplicate?
>
>My testing code does large numbers of creations and deletions of users so the
>deleted uid records are building up.

I think it's mostly that this is an unexpected user case.

You've probably seen this, but the UniqueIDFactory behaves differently when
the real system is running vs. when the test suite is running.  In the latter
case, we don't actually create new UID records in the database.  Instead we
use a file (protected by a lock) to monotonically increment a user-friendly
UID.  The testing machinery is hooked up to this so that when we reset the
"database" between tests, the uid factory gets reset too.

Under normal execution, we create a uuid4() instance, which generates a random
UUID, which is stored in the database, exactly so we can guarantee no
duplicates (they are unlikely to happen, but we have to make sure).

What I didn't expect was for there to be a testing scenario which would hit
the core while it was under normal operation mode, rather than testing mode.
I think that's what you're doing, right?

If so, then indeed, the UID table never gets cleared, and the UID for deleted
users never gets deleted.

I'm wary of deleting the UID when the user is deleted.  It seems like this
could leave us open to vulnerabilities where a UID gets reassigned to a new
user.  Your tests can't directly manipulate the database since you have to go
through the REST API.

If this is really a problem for you, then we'll have to expose something in
the REST API for you to clear out the UID table, or at least specific UIDs.
What I could imagine is that, under some situations (e.g. the presence of an
environment variable perhaps?) a new top-level resource would get exposed
called `<api>/testing` and under that, would be resources you could touch
(DELETE?) that would reset bits of the database for you.

For example:

    DELETE <api>/testing/uid_table

would drop all UID rows.  It would be up to you to call that at the
appropriate time.

Thoughts?

Cheers,
-Barry