Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-10-17T14:38:15Zhttps://lab.civicrm.org/dev/core/-/issues/4005Minor formatting gripes with Contributions UserDashboard.tpl2023-10-17T14:38:15ZAdam WoodMinor formatting gripes with Contributions UserDashboard.tplRaising this as a minor residual issue / action vaguely related to historic issues https://lab.civicrm.org/dev/core/-/issues/2034 and https://lab.civicrm.org/dev/core/-/issues/2129, namely some incidental formatting issues spotted in the...Raising this as a minor residual issue / action vaguely related to historic issues https://lab.civicrm.org/dev/core/-/issues/2034 and https://lab.civicrm.org/dev/core/-/issues/2129, namely some incidental formatting issues spotted in the user dashboard template for recurring contributions.
Minor issues relating to spacing and formatting, will raise PR to close off.
1. No handling for if (installments == 0), i.e. the recurring contribution is open-ended. Just leaves a blank string which is confusing to users.
2. No spacing between clauses in 'Terms' - makes difficult to read. Also untranslated strings.
3. Unnecessary colon after 'Terms' in table header (doesn't match other header cells).
Screenshot below shows issues.
![image](https://user-images.githubusercontent.com/72983627/205190951-4db837e1-85df-4e38-a8b4-77ab1550a44b.png)
![image](https://user-images.githubusercontent.com/72983627/205190481-e8d642a5-9956-4fc3-a0d2-51f16187dca1.png)https://lab.civicrm.org/dev/core/-/issues/4004Fatal error in a Scheduled Job should not prevent other jobs runs from happening2022-11-30T08:31:30ZMichael McAndrewFatal error in a Scheduled Job should not prevent other jobs runs from happeningTake the example of a typical site with ~10 cron jobs configured to run every 5 minutes. The jobs are always run in the same order.
If job 3 exits with a fatal error, the following jobs will not run so a single failing job can cause ma...Take the example of a typical site with ~10 cron jobs configured to run every 5 minutes. The jobs are always run in the same order.
If job 3 exits with a fatal error, the following jobs will not run so a single failing job can cause many others to also 'fail' even if there is nothing wrong with them.
I don't think you can catch Fatal errors but wondering if there is another approach we can take (using sub processes or similar?) that will make our cron more resilient to failure within a specific job.https://lab.civicrm.org/dev/core/-/issues/4003Adding contacts via profile should reflect in source2023-01-24T16:14:59ZyashodhaAdding contacts via profile should reflect in source It would be helpful to have source field reflect the date of creation of contact and profile used.
**Proposal**
When a contact is created via a standalone profile, this information is added to the source field of the contact.
It shou... It would be helpful to have source field reflect the date of creation of contact and profile used.
**Proposal**
When a contact is created via a standalone profile, this information is added to the source field of the contact.
It should show : Profile *'profile name'* on *added date*.
This would be helpful in searches and very relevant to source field.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4002API4 throws an exception when using `IN` and pseudoconstants aren't resolved2023-03-15T15:13:48ZJonGoldAPI4 throws an exception when using `IN` and pseudoconstants aren't resolvedConsider this API call in `mjwshared` (pinging @mattwire since he'll be interested):
```php
$paymentProcessorIDs = \Civi\Api4\PaymentProcessor::get(FALSE)
->addWhere('payment_processor_type_id:name', 'IN', ['Stripe', 'Globalpayments']...Consider this API call in `mjwshared` (pinging @mattwire since he'll be interested):
```php
$paymentProcessorIDs = \Civi\Api4\PaymentProcessor::get(FALSE)
->addWhere('payment_processor_type_id:name', 'IN', ['Stripe', 'Globalpayments'])
->execute()
```
This throws a fatal error when run if you don't have Stripe or Globalpayments installed. However, this seems inconsistent:
* If your operator is `=` not `IN`, you just get an empty set (e.g. `cv api4 PaymentProcessor.get +w 'payment_processor_type_id:name = "fake processor"'`).
* If your operator is `IN` but you're not using pseudoconstant lookup, you get an empty set, e.g. `cv api4 PaymentProcessor.get +w 'payment_processor_type_id IN [123456,234567]'`.
From a DX perspective, I think the correct result on the code in `mjwshared` is to return an empty set.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4001Quick Search won't consider custom field groups2022-11-30T08:29:56Zartur.smigielskiQuick Search won't consider custom field groupsOverview
----------------------------------------
Quick search menu allow to select searchable custom fields but won't identify them by group
Reproduction steps
----------------------------------------
1. Add two groups for custom field...Overview
----------------------------------------
Quick search menu allow to select searchable custom fields but won't identify them by group
Reproduction steps
----------------------------------------
1. Add two groups for custom fields, any name, ex. group_1, group_2
2. For each of them add field with the same name "customnumber", searchable
3. Fill that field with random values for diffrent users
4. Edit quick search panel and pick one of that fields
5. Use quick search panel in menu
Current behaviour
----------------------------------------
It won't find matching records for group_1.customnumber or group_2.customnumber, it will always be the same field group_2.customnumber.
Reason: \CRM_Admin_Page_AJAX::getSearchOptions won't have info about custom field group, so it is searching only by name
```
CRM_Core_DAO::getFieldValue('CRM_Core_DAO_CustomField', substr($key, 7), 'id', 'name')
```
Expected behaviour
----------------------------------------
Search for group_1.customnumber or group_2.customnumber depending of which will be selected in quicksearch panelhttps://lab.civicrm.org/dev/core/-/issues/4000only update `contributionRecur` when `templateContribution` is updated IF it ...2023-03-16T21:47:09Zeileenonly update `contributionRecur` when `templateContribution` is updated IF it is actively marked as suchIn https://github.com/civicrm/civicrm-core/pull/21473 code was added to update the Currency and Amount of the template contribution is updated. However, the code appears to me to be too aggressive and updating the amount or currency of A...In https://github.com/civicrm/civicrm-core/pull/21473 code was added to update the Currency and Amount of the template contribution is updated. However, the code appears to me to be too aggressive and updating the amount or currency of ANY contribution in the series causes it to update. There are good reasons to update individual contributions without any implicit template update.5.61.0https://lab.civicrm.org/dev/core/-/issues/3999Unable to delete Price field2022-11-21T20:52:46ZMonish DebUnable to delete Price fieldSteps to replicate:
2. Create a any kind of price-field (In this example I have created a checkbox field)
1. Created a price set used for any one of the civi component
3. Then delete the price-field
Error:
> Unable to delete the '...Steps to replicate:
2. Create a any kind of price-field (In this example I have created a checkbox field)
1. Created a price set used for any one of the civi component
3. Then delete the price-field
Error:
> Unable to delete the '' Price Field - it is currently in use by one or more active events or contribution pages or contributions or event templates.
Expected: The price set is not used in any donation or event page, then one should be allowed to delete the price-field
Demo:
![after1](/uploads/321c38eaa3707cbb9ac7a6bb020f484f/after1.gif)5.56.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3998Add phpunit-bridge to unit testing2022-11-22T07:23:46ZDaveDAdd phpunit-bridge to unit testingSee https://github.com/civicrm/civicrm-core/pull/25009 for the results of what currently happens. The idea is that e.g. some php 8.x deprecations get hidden, but this package helps flush them out.
Some things that would need doing:
* A...See https://github.com/civicrm/civicrm-core/pull/25009 for the results of what currently happens. The idea is that e.g. some php 8.x deprecations get hidden, but this package helps flush them out.
Some things that would need doing:
* Adjusting the two propertybag tests so that they aren't trying to do the same thing. Or whatever the issue is there.
* A test listener(? or something) so that the deprecations become more visible rather than buried in the run output.
* What is "THE ERROR HANDLER HAS CHANGED!" about, and why is it in GIANT LETTERS? It appears after some test suite runs instead of where you would expect to see the deprecations. Possibly the suites where it appears somehow have their own error handlers in a way where it conflicts with phpunit-bridge.
FYI @totten @seamuslee. Not asking you to do anything just something you might be interested in.
P.S. To get a stack trace showing exactly where the deprecation is happening, you need to run locally and set SYMFONY_DEPRECATIONS_HELPER to a regex that matches the deprecation notice, as per https://symfony.com/doc/current/components/phpunit_bridge.html#display-the-full-stack-trace.
P.P.S. On windows depending on which of the 3^4 options you chose when you installed git, using `/` as the regex terminator confuses it and it gets rewritten as `C:/path/to/git/<the regex>`https://lab.civicrm.org/dev/core/-/issues/3997FormBuilder filter fails on some fields2022-11-28T09:20:40Zaydunsaidan.saunders@squiffle.ukFormBuilder filter fails on some fieldsOverview
----------------------------------------
On some fields, a FormBuilder filter works when a value is entered but deleting the filter value does not show the full listing.
Reproduction steps
--------------------------------------...Overview
----------------------------------------
On some fields, a FormBuilder filter works when a value is entered but deleting the filter value does not show the full listing.
Reproduction steps
----------------------------------------
1. In SearchKit, create a search of CaseTypes
2. Display the ID & Title
3. Create a table display - default settings
4. Create a FormBuilder form
5. Add Case Type Title as a filter
6. Add route, name, save.
7. View page
8. Should see listing of case types
9. In filter box, type 'sup' - should filter correctly to show Housing Support
10. then delete 'sup' from the filter
Current behaviour
----------------------------------------
Does not show all results. Angular error in browser 'val is undefined'
Expected behaviour
----------------------------------------
It should go back to showing all results
Environment information
----------------------------------------
* __CiviCRM:__ _Master_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
Comments
----------------------------------------
Verified on dmaster.
This is only on some fields. Eg doing the same for Case instead of Case Type works as expected.colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3996Event Registration that has error in Profile should continue to propagate Lin...2022-11-22T14:36:05ZshaneonabikeEvent Registration that has error in Profile should continue to propagate Line ItemsTo be honest I didn't know how to clearly define this title so feel free to change it.
## Problem
We encountered an interesting situation whereby during an Event registration the actual payment went through, but the Line items were mis...To be honest I didn't know how to clearly define this title so feel free to change it.
## Problem
We encountered an interesting situation whereby during an Event registration the actual payment went through, but the Line items were missing. When I looked further I discovered that there was an error due to missing / incorrectly configured fields in a Profile that was part of the Event registration.
This Profile was throwing an Exception, because it could not insert the record into the DB. I realize it makes sense to actually return that Exception, but what I question is whether the line items shouldn't be recorded. In this case, the transaction is completed (below), but the line items aren't there because of the exception.
![Selection_002](/uploads/45666402495106c8814a8de1d2837f1b/Selection_002.png)
## Recreate
1. Create a Custom Field set associated to a Contact, and add several fields
2. Create profile and add those fields
3. Create an Event
4. Add that Profile to the Event
5. Add a custom Price Set with several fields
6. Save
From this point, I'm not certain how this came about but I'm guessing the next steps would be:
1. Create a new set of Custom Fields identical to above and recreate associated to Participant and your Event type
1. Delete the first original Custom Field set, but not the profile
2. Register for the Event
I think where this happens is when the actual ```entity_id``` clashes (well in my case it was). So you would need to register multiple times to make this happen. In the DB teh value table for us was
```
civicrm_value_collector_det_16 | CREATE TABLE `civicrm_value_collector_det_16` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Default MySQL primary key',
`entity_id` int(10) unsigned NOT NULL COMMENT 'Table that this extends',
`name_of_individual_collecting_th_50` varchar(255) DEFAULT NULL,
`is_someone_collecting_this_order_51` tinyint(4) DEFAULT NULL,
`phone_number_52` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `unique_entity_id` (`entity_id`),
KEY `INDEX_phone_number_52` (`phone_number_52`),
KEY `INDEX_name_of_individual_collecting_th_50` (`name_of_individual_collecting_th_50`),
CONSTRAINT `FK_civicrm_value_collector_det_16_entity_id` FOREIGN KEY (`entity_id`) REFERENCES `civicrm_contact` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=140 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci |
```
## Actual Error
_DB Error: Constraint_ via
```
[debug_info] => INSERT INTO civicrm_value_collector_det_16 ( `is_someone_collecting_this_order_51`,
`name_of_individual_collecting_th_50`,`phone_number_52`,`entity_id` ) VALUES ( 0,'','',128 )
ON DUPLICATE KEY UPDATE `is_someone_collecting_this_order_51` = 0,
`name_of_individual_collecting_th_50` = '',`phone_number_52` = ''
[nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails
(`sitesite`.`civicrm_value_collector_det_16`, CONSTRAINT
`FK_civicrm_value_collector_det_16_entity_id` FOREIGN KEY (`entity_id`)
REFERENCES `civicrm_contact` (`id`) ON DELETE CASCADE)]
```
## Possible improvements
1. Process the transaction
2. Process line items
3. Save to DB
4. Process Profiles after?
or
1. Process transaction
2. Process Profile (if an exception cache it)
3. Continue as before
4. Throw Exception at end?
I'm not sure, but the fact that the transaction is passed we should ensure that the line items are saved too.
Sorry for the long text!https://lab.civicrm.org/dev/core/-/issues/3995FormBuilder: Autocomplete causes numerous network requests2022-11-18T16:54:03Zaydunsaidan.saunders@squiffle.ukFormBuilder: Autocomplete causes numerous network requestsOverview
----------------------------------------
On a FormBuilder form using an 'Existing entity' lookup results in multiple network requests.
Reproduction steps
----------------------------------------
1. Go to FormBuilder
2. Create n...Overview
----------------------------------------
On a FormBuilder form using an 'Existing entity' lookup results in multiple network requests.
Reproduction steps
----------------------------------------
1. Go to FormBuilder
2. Create new submission form (by default is for Individual)
3. Drag an 'Existing Contact' field onto the display
4. Add a page route, save, view page
5. Open up your browser's dev tools
6. Type something in 'existing contact' field
7. Select an entry
8. Observe repeated sequence of 'prefill', 'autocomplete' network requests:
![image](/uploads/04e0360aa2ac09ca5ab96248db02c41b/image.png)
Image from dmaster.demo.civicrm.org
Environment information
----------------------------------------
* __CiviCRM:__ _Master_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3994Auto renew options for membership types are not saving for a contribution page2023-12-07T00:06:08ZKurund JalmiAuto renew options for membership types are not saving for a contribution pageSteps to replicate on vanilla CiviCRM install
- Membership type configuration
![Screenshot_from_2022-11-18_10-51-50](/uploads/02d45ded17660376a461d6738c287c48/Screenshot_from_2022-11-18_10-51-50.png)
- In the contribution page configur...Steps to replicate on vanilla CiviCRM install
- Membership type configuration
![Screenshot_from_2022-11-18_10-51-50](/uploads/02d45ded17660376a461d6738c287c48/Screenshot_from_2022-11-18_10-51-50.png)
- In the contribution page configuration try to make option 'Required' and save.
![Screenshot_from_2022-11-18_10-52-30](/uploads/9f50922426022defea7b99c53a386def/Screenshot_from_2022-11-18_10-52-30.png)
- However, it not saved
![Screenshot_from_2022-11-18_10-52-41](/uploads/57717f65ddd9e0df971821cafade9752/Screenshot_from_2022-11-18_10-52-41.png)5.69.0Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/drupal/-/issues/184Remove 8 from Composer package and file names?2022-11-18T14:39:33ZresgaRemove 8 from Composer package and file names?[Drupal 8 reached end-of-life on November 2, 2021](https://www.drupal.org/psa-2021-06-29), but the number 8 is still used when installing CiviCRM with Composer.
Since the upgrade path from Drupal 9 to 10, 10 to 11, etc. should be easier...[Drupal 8 reached end-of-life on November 2, 2021](https://www.drupal.org/psa-2021-06-29), but the number 8 is still used when installing CiviCRM with Composer.
Since the upgrade path from Drupal 9 to 10, 10 to 11, etc. should be easier than from Drupal 7 to 8, and the underlying technical foundation go through less changes for the foreseeable future, would it be possible to drop the number 8 in CiviCRM package names at some point?
**Now**
`composer require civicrm/civicrm-{core,packages,drupal-8}`
**Possible at some point?**
`composer require civicrm/civicrm-{core,packages,drupal}`
For Drupal 7 it's best to keep using `drupal-7`, to keep the two versions separated.https://lab.civicrm.org/dev/core/-/issues/3993Order wrong processing wait list participants2023-02-09T07:20:44ZDevAppOrder wrong processing wait list participantsThe CiviCRM wait list appears to offer the last person on the list the place, rather than the first place (oldest) registration.
Seemingly others are having this issue as well: https://civicrm.stackexchange.com/questions/37944/order-pro...The CiviCRM wait list appears to offer the last person on the list the place, rather than the first place (oldest) registration.
Seemingly others are having this issue as well: https://civicrm.stackexchange.com/questions/37944/order-processing-waitlist-participantshttps://lab.civicrm.org/dev/core/-/issues/3992Expose created date column in contact reports2022-11-16T21:33:39ZyashodhaExpose created date column in contact reportsExpose created date column in contact reports and as filter as well.Expose created date column in contact reports and as filter as well.5.57.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3991Drop php 7.2 support from CiviCRM 5.58 (after 5.57 ESR)2023-11-28T10:48:51ZeileenDrop php 7.2 support from CiviCRM 5.58 (after 5.57 ESR)Per previous efforts to drop PHP version support I propose we drop 7.2 in 5.58. This means people who want another 6 months can use the ESR. Usage numbers for php 7.2 (around 1k) are around the levels where we dropped previous versions &...Per previous efforts to drop PHP version support I propose we drop 7.2 in 5.58. This means people who want another 6 months can use the ESR. Usage numbers for php 7.2 (around 1k) are around the levels where we dropped previous versions & support is starting to get harder - see https://github.com/civicrm/civicrm-core/pull/24952https://lab.civicrm.org/dev/wordpress/-/issues/134Clean URLs system check fails via API or cv2022-11-17T07:25:06ZJonGoldClean URLs system check fails via API or cvAs of CiviCRM 5.55, there is a check if Clean URLs are enabled.
Unfortunately, it does so by checking whether the `get_option()` function exists. This is fine via the web UI where WP boots first, but with `cv` or the API, WP boots afte...As of CiviCRM 5.55, there is a check if Clean URLs are enabled.
Unfortunately, it does so by checking whether the `get_option()` function exists. This is fine via the web UI where WP boots first, but with `cv` or the API, WP boots after CiviCRM. Since `CIVICRM_CLEANURLs` is a constant, once it's set to `0`, it's fixed at `0`.
E.g. in `cv`, `Civi\Cv\Util\BootTrait::_boot_full()` contains the following code!
```php
PharOut::prepare();
$output->writeln('<info>[BootTrait]</info> Call standard cv bootstrap', OutputInterface::VERBOSITY_DEBUG);
\Civi\Cv\Bootstrap::singleton()->boot($this->createBootParams($input, $output));
$output->writeln('<info>[BootTrait]</info> Call core bootstrap', OutputInterface::VERBOSITY_DEBUG);
\CRM_Core_Config::singleton();
$output->writeln('<info>[BootTrait]</info> Call CMS bootstrap', OutputInterface::VERBOSITY_DEBUG);
\CRM_Utils_System::loadBootStrap(array(), FALSE);
```
`\Civi\Cv\Bootstrap::singleton()->boot()` runs and `civicrm.settings.php` is evaluated before WP is booted at `\CRM_Utils_System::loadBootStrap(array(), FALSE)`.
### Next Steps
Maybe `CIVICRM_CLEANURLS` should be part of the `$civicrm_setting` global variable instead of a constant?https://lab.civicrm.org/dev/core/-/issues/3990force deduplication for event registrations: misleading help text → change su...2022-11-17T07:23:57ZAndreasandreas.howiller@civiservice.deforce deduplication for event registrations: misleading help text → change suggested workaround or add feature to CiviEvent?Sometimes you want to intentionally force duplicates for anonymous registrations for certain events. Some users even want this as their default in CiviEvent.
In the profile configuration there is the following hint how you should do th...Sometimes you want to intentionally force duplicates for anonymous registrations for certain events. Some users even want this as their default in CiviEvent.
In the profile configuration there is the following hint how you should do this:
> If you are using the profile as a contact signup and editing form - this option controls what happens if the data matches an existing contact record. Using this option user can update the matching record or create a duplicate record or otherwise he will get a 'duplicate record' warning, and their input will not be saved. Contact matching is based on your configured 'Strict' rule for identifying duplicate contacts. (Weiterlesen...)
>
> This setting is ignored if the profile is embedded in an online contribution, membership signup or event registration form. In this case a contact match always results in the transaction being linked to the matching contact.
>
> In all cases, the check for an existing matching contact uses the default "Individual Strict Duplicate Matching Rule" (match on email address). If you are concerned with existing contact data being over-written by anonymous visitors, you can modify this rule to make matches less likely (or even impossible). For example, if you NEVER want anonymous input to match (i.e. always create a new contact record) - edit that rule and set the 'weight threshold' higher than 10. You will then need to run Find Duplicates periodically using a different rule, and merge any duplicate records with their associated memberships, contributions, etc.
However, this kind of "suggested workaround" no longer works because you can no longer specify an unreachable threshold in the deduplication rules. In any case, the help text would have to be adapted.
However, the question arises how to deal with the actual requirement and I see at least two possibilities:
**Option A: Replacing the workaround**
Recommend in the help text to create an unachievable deduplication rule by using in the rule a field that is never used in the user's event registrations and advice them to set this rule for registrations when needed.
**Option B: add a feature in CiviEvent**
Add a "no deduplication" feature (like there is an option to deactivate deduplication in profiles) and add this option to the duplicate rule dropdown in the event configuration.
Any (other) ideas?https://lab.civicrm.org/dev/core/-/issues/3989Merging contacts should not overwrite empty source2023-07-05T23:48:38ZlarsssandergreenMerging contacts should not overwrite empty sourceIf you merge two contacts, the original with an empty source and the duplicate with some source value, the source value from the duplicate is copied to the original. This doesn't make sense, because the source of the contact is clearly n...If you merge two contacts, the original with an empty source and the duplicate with some source value, the source value from the duplicate is copied to the original. This doesn't make sense, because the source of the contact is clearly not whatever the source of the duplicate contact is — the contact already existed before that!
For example, we have lots of ten year old contacts with no source. A duplicate is created through an event registration now and these contacts can end up with a nonsensical source from an event this year when they have been in our database for a decade.
My proposal:
1. Remove the default selected checkbox for source when merging contacts manually. Source should never be overwritten by default, even if empty for the original contact. Users can still opt to overwrite with the newer source if desired.
2. Never overwrite source when batch merging, even if it is empty in the original contact. I think this is a sensible behaviour that doesn't need user intervention, but if there is a concern about this, we could also flag this as a merge conflict instead in this specific case.https://lab.civicrm.org/dev/core/-/issues/3988Cache race conditions2024-02-16T09:46:55ZJonGoldCache race conditionsA client was asking me to find out why a $2,500 donation failed. I found this error in the logs (full backtrace below):
```
Nov 10 10:58:40 [error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CR...A client was asking me to find out why a $2,500 donation failed. I found this error in the logs (full backtrace below):
```
Nov 10 10:58:40 [error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => -5
[message] => DB Error: already exists
[mode] => 16
[debug_info] => UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5OiJDb21wbGV0ZWQiO2k6MztzOjk6IkNhbmNlbGxlZCI7aTo0O3M6MTI6IkxlZnQgTWVzc2FnZSI7aTo1O3M6MTE6IlVucmVhY2hhYmxlIjtpOjY7czoxMjoiTm90IFJlcXVpcmVkIjtpOjc7czo5OiJBdmFpbGFibGUiO2k6ODtzOjc6Ik5vX3Nob3ciO2k6OTtzOjY6IlVucmVhZCI7aToxMDtzOjU6IkRyYWZ0Ijt9', created_date = FROM_UNIXTIME(1668095920), expired_date = FROM_UNIXTIME(1668117520) WHERE group_name = "metadata_5_54_1" AND path = "CRM_OG_activitystatus_883f1c0c1790789755f726d1e41232c2" [nativecode=1062 ** Duplicate entry 'metadata_5_54_1-CRM_OG_activitystatus_883f1c0c1790789755f726d...' for key 'UI_group_path_date']
[type] => DB_Error
[user_info] => UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5OiJDb21wbGV0ZWQiO2k6MztzOjk6IkNhbmNlbGxlZCI7aTo0O3M6MTI6IkxlZnQgTWVzc2FnZSI7aTo1O3M6MTE6IlVucmVhY2hhYmxlIjtpOjY7czoxMjoiTm90IFJlcXVpcmVkIjtpOjc7czo5OiJBdmFpbGFibGUiO2k6ODtzOjc6Ik5vX3Nob3ciO2k6OTtzOjY6IlVucmVhZCI7aToxMDtzOjU6IkRyYWZ0Ijt9', created_date = FROM_UNIXTIME(1668095920), expired_date = FROM_UNIXTIME(1668117520) WHERE group_name = "metadata_5_54_1" AND path = "CRM_OG_activitystatus_883f1c0c1790789755f726d1e41232c2" [nativecode=1062 ** Duplicate entry 'metadata_5_54_1-CRM_OG_activitystatus_883f1c0c1790789755f726d...' for key 'UI_group_path_date']
[to_string] => [db_error: message="DB Error: already exists" code=-5 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5OiJDb21wbGV0ZWQiO2k6MztzOjk6IkNhbmNlbGxlZCI7aTo0O3M6MTI6IkxlZnQgTWVzc2FnZSI7aTo1O3M6MTE6IlVucmVhY2hhYmxlIjtpOjY7czoxMjoiTm90IFJlcXVpcmVkIjtpOjc7czo5OiJBdmFpbGFibGUiO2k6ODtzOjc6Ik5vX3Nob3ciO2k6OTtzOjY6IlVucmVhZCI7aToxMDtzOjU6IkRyYWZ0Ijt9', created_date = FROM_UNIXTIME(1668095920), expired_date = FROM_UNIXTIME(1668117520) WHERE group_name = "metadata_5_54_1" AND path = "CRM_OG_activitystatus_883f1c0c1790789755f726d1e41232c2" [nativecode=1062 ** Duplicate entry 'metadata_5_54_1-CRM_OG_activitystatus_883f1c0c1790789755f726d...' for key 'UI_group_path_date']"]
)
```
In `CRM_Core_OptionGroup::values()`, we check for a cached result. If we don't find one, we run the query, then cache the result. However, between the `$cache->has()` and `$cache->set()`, this value was added to the cache.
### How to resolve?
It seems to me like there's no way to avoid a race condition without recovering gracefully from this error.
It seems like a failure to write to cache shouldn't be fatal - could we catch `CRM_Utils_Cache_CacheException` and continue execution?
Backtrace
```
Nov 10 10:58:40 [debug] $backTrace = #0 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Error.php(954): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /var/www/mysiten.org/vendor/pear/pear-core-minimal/src/PEAR.php(944): CRM_Core_Error::exceptionHandler(Object(DB_Error))
#2 /var/www/mysiten.org/vendor/pear/db/DB.php(997): PEAR_Error->__construct("DB Error: already exists", -5, 16, (Array:2), "UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#3 /var/www/mysiten.org/vendor/pear/pear-core-minimal/src/PEAR.php(575): DB_Error->__construct(-5, 16, (Array:2), "UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#4 /var/www/mysiten.org/vendor/pear/pear-core-minimal/src/PEAR.php(223): PEAR::_raiseError(Object(DB_mysqli), NULL, -5, 16, (Array:2), "UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...", "DB_Error", TRUE)
#5 /var/www/mysiten.org/vendor/pear/db/DB/common.php(1928): PEAR->__call("raiseError", (Array:7))
#6 /var/www/mysiten.org/vendor/pear/db/DB/mysqli.php(943): DB_common->raiseError(-5, NULL, NULL, "UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...", "1062 ** Duplicate entry 'metadata_5_54_1-CRM_OG_activitystatus_883f1c0c179078...")
#7 /var/www/mysiten.org/vendor/pear/db/DB/mysqli.php(413): DB_mysqli->mysqliRaiseError()
#8 /var/www/mysiten.org/vendor/pear/db/DB/common.php(1234): DB_mysqli->simpleQuery("UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#9 /var/www/mysiten.org/vendor/civicrm/civicrm-packages/DB/DataObject.php(2696): DB_common->query("UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#10 /var/www/mysiten.org/vendor/civicrm/civicrm-packages/DB/DataObject.php(1829): DB_DataObject->_query("UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#11 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/DAO.php(494): DB_DataObject->query("UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...")
#12 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/DAO.php(1675): CRM_Core_DAO->query("UPDATE civicrm_cache SET data = 'YToxMDp7aToxO3M6OToiU2NoZWR1bGVkIjtpOjI7czo5...", FALSE)
#13 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Utils/Cache/SqlGroup.php(137): CRM_Core_DAO::executeQuery("UPDATE civicrm_cache SET data = %1, created_date = FROM_UNIXTIME(%2), expired...", (Array:3), TRUE, NULL, FALSE, FALSE)
#14 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/OptionGroup.php(173): CRM_Utils_Cache_SqlGroup->set("CRM_OG_activitystatus_883f1c0c1790789755f726d1e41232c2", (Array:10))
#15 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/PseudoConstant.php(262): CRM_Core_OptionGroup::values("activity_status", FALSE, FALSE, FALSE, NULL, "name", FALSE, FALSE, "value", "weight")
#16 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/DAO.php(2837): CRM_Core_PseudoConstant::get("CRM_Activity_BAO_Activity", "status_id", (Array:8), "validate")
#17 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Utils/FormattingUtil.php(264): CRM_Core_DAO::buildOptions("status_id", "validate", (Array:10))
#18 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Generic/AbstractAction.php(530): Civi\Api4\Utils\FormattingUtil::getPseudoconstantList((Array:30), "status_id:name", (Array:10), "create")
#19 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Generic/Traits/DAOActionTrait.php(178): Civi\Api4\Generic\AbstractAction->formatWriteValues((Array:10))
#20 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Generic/DAOSaveAction.php(30): Civi\Api4\Generic\DAOSaveAction->formatWriteValues((Array:10))
#21 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Provider/ActionObjectProvider.php(69): Civi\Api4\Generic\DAOSaveAction->_run(Object(Civi\Api4\Generic\Result))
#22 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(149): Civi\Api4\Provider\ActionObjectProvider->invoke(Object(Civi\Api4\Generic\DAOSaveAction))
#23 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/Api4/Generic/AbstractAction.php(250): Civi\API\Kernel->runRequest(Object(Civi\Api4\Generic\DAOSaveAction))
#24 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/BAO/Contribution.php(552): Civi\Api4\Generic\AbstractAction->execute()
#25 /var/www/mysiten.org/vendor/civicrm/civicrm-core/api/v3/utils.php(1319): CRM_Contribute_BAO_Contribution::create((Array:23))
#26 /var/www/mysiten.org/vendor/civicrm/civicrm-core/api/v3/Contribution.php(87): _civicrm_api3_basic_create("CRM_Contribute_BAO_Contribution", (Array:23), "Contribution")
#27 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_contribution_create((Array:23))
#28 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(149): Civi\API\Provider\MagicFunctionProvider->invoke((Array:8))
#29 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest((Array:8))
#30 /var/www/mysiten.org/vendor/civicrm/civicrm-core/api/api.php(133): Civi\API\Kernel->runSafe("Contribution", "create", (Array:10))
#31 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/BAO/Contribution.php(3848): civicrm_api3("Contribution", "create", (Array:10))
#32 /var/www/mysiten.org/vendor/civicrm/civicrm-core/api/v3/Contribution.php(522): CRM_Contribute_BAO_Contribution::completeOrder((Array:5), NULL, 21523, NULL)
#33 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_contribution_completetransaction((Array:9))
#34 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(149): Civi\API\Provider\MagicFunctionProvider->invoke((Array:8))
#35 /var/www/mysiten.org/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest((Array:8))
#36 /var/www/mysiten.org/vendor/civicrm/civicrm-core/api/api.php(133): Civi\API\Kernel->runSafe("contribution", "completetransaction", (Array:9))
#37 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Confirm.php(2412): civicrm_api3("contribution", "completetransaction", (Array:9))
#38 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Confirm.php(861): CRM_Contribute_Form_Contribution_Confirm->processFormSubmission("100769")
#39 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Form.php(573): CRM_Contribute_Form_Contribution_Confirm->postProcess()
#40 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Main.php(1472): CRM_Core_Form->mainProcess()
#41 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Contribute/Form/Contribution/Main.php(1220): CRM_Contribute_Form_Contribution_Main->skipToThankYouPage()
#42 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Form.php(573): CRM_Contribute_Form_Contribution_Main->postProcess()
#43 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Upload.php(152): CRM_Core_Form->mainProcess()
#44 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/QuickForm/Action/Upload.php(119): CRM_Core_QuickForm_Action_Upload->realPerform(Object(CRM_Contribute_Form_Contribution_Main), "upload")
#45 /var/www/mysiten.org/vendor/civicrm/civicrm-packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Upload->perform(Object(CRM_Contribute_Form_Contribution_Main), "upload")
#46 /var/www/mysiten.org/vendor/civicrm/civicrm-packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contribute_Form_Contribution_Main), "upload")
#47 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Controller.php(355): HTML_QuickForm_Page->handle("upload")
#48 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(319): CRM_Core_Controller->run((Array:3), NULL)
#49 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem((Array:18))
#50 /var/www/mysiten.org/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:3))
#51 /var/www/mysiten.org/web/modules/contrib/civicrm/src/Civicrm.php(88): CRM_Core_Invoke::invoke((Array:3))
#52 /var/www/mysiten.org/web/modules/contrib/civicrm/src/Controller/CivicrmController.php(80): Drupal\civicrm\Civicrm->invoke((Array:3))
#53 [internal function](): Drupal\civicrm\Controller\CivicrmController->main((Array:3), "")
#54 /var/www/mysiten.org/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array((Array:2), (Array:2))
#55 /var/www/mysiten.org/web/core/lib/Drupal/Core/Render/Renderer.php(564): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#56 /var/www/mysiten.org/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#57 /var/www/mysiten.org/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext((Array:2), (Array:2))
#58 /var/www/mysiten.org/vendor/symfony/http-kernel/HttpKernel.php(159): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#59 /var/www/mysiten.org/vendor/symfony/http-kernel/HttpKernel.php(81): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#60 /var/www/mysiten.org/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#61 /var/www/mysiten.org/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#62 /var/www/mysiten.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#63 /var/www/mysiten.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#64 /var/www/mysiten.org/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#65 /var/www/mysiten.org/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#66 /var/www/mysiten.org/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#67 /var/www/mysiten.org/web/core/lib/Drupal/Core/DrupalKernel.php(709): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, TRUE)
#68 /var/www/mysiten.org/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#69 {main}
```5.61.0