DatabaseExceptionWrapper: module name too long

(1) I think doing this may then have ramifications for not being able to download it later via composer, since it will have the project name wrong?

(2) I think the actual issue is with the endpoint/API - it seems to be repeating the characters / name over and over. That actual project name is 31 characters long.

https://www.drupal.org/project/augmentor_google_cloud_text_to_speech →

We should coordinate with d.o and know what their max length is for project node titles (255?) and just use that on ours (we probably already are? But I haven't looked at the schema).

I'll see if I can get @fjgarlin to check out this project on the API site.

https://www.drupal.org/jsonapi/index/project_modules?filter%5Bmachine_na... →

...
"title": "Google Cloud Text-to-Speech Augmentor",
...
"field_composer_namespace": "drupal/augmentor_google_cloud_text_to_speech-augmentor_google_cloud_text_to_speech",
...
"field_project_machine_name": "augmentor_google_cloud_text_to_speech",
...

The "field_composer_namespace" value is 82 characters long.
The data seems correct, so it must be something happening in the code.

The MR does not solve the issue. The problem is that "keyValue" has a limit for the "name" column

The issue is in this line, in PB code: https://git.drupalcode.org/project/project_browser/-/blob/2.0.x/src/Enab...

I suggest that we "md5" (or whatever technique is best) the "$cache_key".
Something like this:
$cache_key = md5($this->getQueryCacheKey($query));

I created an MR with the fix: https://git.drupalcode.org/project/project_browser/-/merge_requests/802/...

I will wait on tests, but this has been discussed in https://drupal.slack.com/archives/C01UHB4QG12/p1747231711012519 with Adam & Fran.

Actually, we were already using md5 by calling getQueryCacheKey. I changed it to "sha1".

However, given the above output in the issue summary, this is not related to storing the "query:...", it's got to be something else.

aha! found it!

https://git.drupalcode.org/project/project_browser/-/blob/2.0.x/src/Proj...

Two ways to go around it.
- We change that part, by adding sha1 around it.
- Or we add a “safe” ID https://git.drupalcode.org/project/project_browser/-/blob/2.0.x/src/Plug...

I think option 1 is good as it will apply to all plugins.

MR with approach suggested in this thread: https://drupal.slack.com/archives/C01UHB4QG12/p1747231711012519

fjgarlin → closed merge request !796

Closed MR796 (thanks!!) in favor of MR802.

We shouldn't have the ID be generated by conditions ("if too long, do this"). We should always do the same kind of processing to it, so that it's as deterministic and consistent as possible.

Cool. Feedback applied.

Looks okay to me but some tests will need to be adjusted.

I left some dev notes in the MR to explain the reasoning behind some code.

We are just normalizing the keys when we store something in the keyValue store and when we retrieve it we apply the normalization to the given ID. We don't need to normalize keys anywhere else.

This is ready for review.

The feedback in the MR was addressed. Tests are happy (HEAD fails in the same ones, so no regressions).

A few small stylistic changes but this otherwise makes sense to me.

ok, actually merged on 2.1.x and cherry-pick'd back to 2.0.x now. really fixed!