It seems that due to a recent change the rev_multilink feature is broken.
These are injected into the database structure during initialization.
My current guess is that it no longer works after the change 
6514:a036712c96f4
Enable HTTP/1.1 support for roundup-server

The behavior is very peculiar: On the first request everything is fine,
the multilinks I have are named 'planning_role' and 'vie_user_ml'.
When I set a breakpoint in a function called from a html template on
the first request I'm getting the full list:

(Pdb) p sorted(db._db.user.properties.keys())
['ad_domain', 'address', 'alternate_addresses', 'business_responsible', 'clearance_by', 'contacts', 'csv_delimiter', 'department_temp', 'entry_date', 'firstname', 'guid', 'hide_message_files', 'job_description', 'lastname', 'lunch_duration', 'lunch_start', 'nickname', 'password', 'pictures', 'planning_role', 'position_text', 'queries', 'realname', 'reduced_activity_list', 'roles', 'room', 'scale_seniority', 'sex', 'status', 'subst_active', 'substitute', 'supervisor', 'sync_foreign_key', 'timetracking_by', 'timezone', 'timing_info', 'tt_lines', 'username', 'vie_user', 'vie_user_bl_override', 'vie_user_ml']

In a subsequent request I'm getting:
(Pdb) p sorted(db._db.user.properties.keys())
['ad_domain', 'address', 'alternate_addresses', 'business_responsible', 'clearance_by', 'contacts', 'csv_delimiter', 'department_temp', 'entry_date', 'firstname', 'guid', 'hide_message_files', 'job_description', 'lastname', 'lunch_duration', 'lunch_start', 'nickname', 'password', 'pictures', 'position_text', 'queries', 'realname', 'reduced_activity_list', 'roles', 'room', 'scale_seniority', 'sex', 'status', 'subst_active', 'substitute', 'supervisor', 'sync_foreign_key', 'timetracking_by', 'timezone', 'timing_info', 'tt_lines', 'username', 'vie_user', 'vie_user_bl_override']

Note that the mentioned properties are missing.

When I let the webserver time out and issue a new request, the rev_multilink properties are there again.
So it looks like somewhere in the re-use of html connections the database is not
fully set up like when it is initialized from scratch. I'm looking into this now.

Turns out that post_init was never explicitly called in roundup/instance.py
I've added a call when the freshly-created db is used.
Note that there probably is another code path that calls db.post_init
but post_init is supposed to be idempotent.

Ah, for the record: This if fixed in 6536:b78c45828e42

I just pushed this to CI.

I assume we are calling post_init in the database backend which invokes hyperdb's
post_init by calling:

  super(Database, self).post_init()

in the backend post_init methods.

Did this show up with my HTTP 1.1 patches because under 1.1 only one
request was done per connection and each request opens a new db handle?

Also is there a way to test for this error case as well as validating that 
post_init is idempotent now and forever?

On Mon, Nov 29, 2021 at 08:34:11PM +0000, John Rouillard wrote:
> 
> Also is there a way to test for this error case as well as validating that 
> post_init is idempotent now and forever?

At least in some of the regression tests the post_init is called
multiple times, that's why I noticed during implementation of the
rev_multilink feature.

And concerning the other question: Yes I think the backend calls
post_init when the database updates (version change) are performed.
And this does not seem to happen when multiple requests are processed in
the new server implementation. Interestingly it *is* correctly performed
in wsgi which I'm mostly using.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: office@runtux.com