TypeError: _genpass_valid_intf_value(): Argument #2 ($value) must be of type int, null give

Seems like it stems from this commit
https://git.drupalcode.org/project/genpass/-/commit/2f1d3d93

The problem is that is too generic and applies to all forms... needs a narrower scope.

Previous versions were tied to just:
user_register_form and user_form, I'll propose re-implementing that restriction

That might be a good fix regardless but my actual problem is the config didn't upgraded.

Resaving it with the new config options seemed to fix the issue. Could be a pbcak error...

This patch would break the entirety of the new code in the form_alter, which allows a module to configure genpass to alter any form. It is not meant to be limited to those two forms, but it does need the new configuration setup. Did you run the schema updates?

Perhaps I should be guarding the form values. Or perhaps I need to fix the upgrade path. Hard to tell what has happened.

Has the issue disappeared completely with the newly saved config?

@ELC thanks for your quick response. Yeah I think it might be something on our end with the config. Might have been related to the new requirement around email verification... or maybe we forgot to commit the updated config after the upgrade... it's hard to tell and we have it on a number of sites and I think this only happened to one.

I'll close this to keep your queue clean and we can chalk it up to user error.
If others report this maybe we can do some of your suggestions above but for now YAGNI

Side note I know you tried to mitigate the performance issues of calling HOOK_form_alter on every form but you might want to find a way to shortcut it so that if something doesn't exist in the form or something it can just exit without further function calls. Just a suggestion 2¢

The performance mitigation on form_alter should be very fast - it uses a static cache (ie. kept in memory from first call) and the normal cache backing that up, before finally rebuilding that cache content.

The call to check if a form is one to alter is an isset(array[$form_id]) with the array pulled from static cache for subsequent calls. This is one more fast function call than doing an isset(array[$form_item]) - the issue with checking the form for a key directly is that it is now the key name that is configurable.

So the most called path for this form_alter with involve:

1. A single default cache get on the first form_alter
2. per subsequent form_alter; a single static cache get

The one option for speeding this up would be to not use cache.default, but instead use cache.discovery or a custom cache which could be assigned to another cache type like redis while keeping the cache.default in database.

If this is somehow not fast, I'd love to be given the heads up.

Gee golly gosh. It has a bug which resets the cache on every call. Oh dear.

🐛 Call to get/generate user forms array uses wrong parameters Active

That is a critical bug I'll be pushing into a release asap. Sorry about that.

This ended up being code that needed to be fixed to work around the situation where the module code has been updated from alpha, but update function has not yet been run.

In this instance, the default settings which are used to ensure that all options provided via hook are valid, are not available and throw the error given in the OP.

This would prevent a user trying to run upgrades via the UI of the site from being able to navigate to or run the updates. The word-around would be run updates via drush.

To fix, always provide a default value even if after upgrade they will always be set.

It did not get auto-posted due to the status of the issue when I pushed it, but here's the commit:
Issue #3395050 by ELC: Always provide default value.

ELC → closed merge request !16

RE #8 I'll take your word for it, sounds like you've thought of your options deeply. My experience is that if something gets called frequently (usually more than 5K times on a request, however) it becomes significant to limit it's calls, and isset() is super fast compared to a user defined function. I used to do a l ot of performance patches → (read micro-optimizations), with lots of xhprof tests to back up my stuff, since I have no backup and only intuition, your thorough thinking of the problem are much more valid than mine;)

RE #9 And I'm glad the issue found something (indirectly!)

Automatically closed - issue fixed for 2 weeks with no activity.