UPGRADE ERROR/ISSUE - Some Email Addresses seem to have 'lost' their relationship to Account, Lead and other module records

I’m not 100% sure what may have caused, or ‘be’ causing this issue.
I upgraded to 7.14.2, and php to 8.2 (and Ubuntu to 20x).

I noticed when I upgraded from 7.14 to 7.14.2, i got a white screen at the end of the upgrade process…but didn’t notice any ‘issues’ with the newly installed app, until this morning, when we noticed that a fair number (190 or so) “Account” records seems to ‘not’ have Email1 addressed any more, when they ‘did’ have these addresses last week. (I have a report that we review each week).

I looked in the email_addr_bean_rel table, and the addresses ‘are’ in there…but are not being shown in the record (detail view), and my reporting is telling me that 190ish have no email address.

I ‘suspect’ that perhaps some relationships with ‘other’ modules and their emails may have been damaged too, but no specific evidence there…

I did run a quick repair/rebuild, and I’ve run virtually all of the other ‘rebuild’ functions available in the repair screen…but to no avail.

NOTE
I’m also seeing that the diagnostic tool will not run…I ‘believe’ I have the permissions and owners right?

So, I’m looking around to see if logs will help…but is there some ‘best’ practice at this stage??
@pgr - how ‘bad’ does this sound??
Do you think this is recoverable, or do you think I’m looking at a re-install + data import??

BTW: Here is the end of the output of the upgradeWizard.log file:

Fri, 17 Nov 2023 14:54:44 -0500 [UpgradeWizard] - database repaired
Fri, 17 Nov 2023 14:54:44 -0500 [UpgradeWizard] -  Start Rebuilding the config file again
Fri, 17 Nov 2023 14:54:44 -0500 [UpgradeWizard] -  Finish Rebuilding the config file again
Fri, 17 Nov 2023 14:54:44 -0500 [UpgradeWizard] - Begin upgrade_connectors
Fri, 17 Nov 2023 14:54:44 -0500 [UpgradeWizard] - End upgrade_connectors
Fri, 17 Nov 2023 14:54:44 -0500 [UpgradeWizard] - Running UpgradeRemoval instance UpgradeRemoval65x
Fri, 17 Nov 2023 14:54:44 -0500 [UpgradeWizard] - Files will be backed up to custom/backup
Fri, 17 Nov 2023 14:54:44 -0500 [UpgradeWizard] - jssource/src_files/include/javascript/jquery.js
Fri, 17 Nov 2023 14:54:44 -0500 [UpgradeWizard] - modules/jjwg_Areas/javascript/jquery-1.4.2.min.js
Fri, 17 Nov 2023 14:54:44 -0500 [UpgradeWizard] - modules/jjwg_Areas/javascript/jquery-1.8.0.min.js
Fri, 17 Nov 2023 14:54:44 -0500 [UpgradeWizard] - modules/jjwg_Maps/DataTables/media/js/jquery.js
Fri, 17 Nov 2023 14:54:44 -0500 [UpgradeWizard] - modules/jjwg_Maps/javascript/jquery-1.8.0.min.js
Fri, 17 Nov 2023 14:54:57 -0500 [UpgradeWizard] - setting session variables...
Fri, 17 Nov 2023 14:54:59 -0500 [UpgradeWizard] - [At end.php]
Fri, 17 Nov 2023 14:54:59 -0500 [UpgradeWizard] - About to repair the database.
Fri, 17 Nov 2023 14:55:02 -0500 [UpgradeWizard] - database repaired
Fri, 17 Nov 2023 14:55:02 -0500 [UpgradeWizard] -  Start Rebuilding the config file again
Fri, 17 Nov 2023 14:55:02 -0500 [UpgradeWizard] -  Finish Rebuilding the config file again
Fri, 17 Nov 2023 14:55:02 -0500 [UpgradeWizard] - Begin upgrade_connectors
Fri, 17 Nov 2023 14:55:02 -0500 [UpgradeWizard] - End upgrade_connectors
Fri, 17 Nov 2023 14:55:02 -0500 [UpgradeWizard] - Running UpgradeRemoval instance UpgradeRemoval65x
Fri, 17 Nov 2023 14:55:02 -0500 [UpgradeWizard] - Files will be backed up to custom/backup
Fri, 17 Nov 2023 14:55:02 -0500 [UpgradeWizard] - jssource/src_files/include/javascript/jquery.js
Fri, 17 Nov 2023 14:55:02 -0500 [UpgradeWizard] - modules/jjwg_Areas/javascript/jquery-1.4.2.min.js
Fri, 17 Nov 2023 14:55:02 -0500 [UpgradeWizard] - modules/jjwg_Areas/javascript/jquery-1.8.0.min.js
Fri, 17 Nov 2023 14:55:02 -0500 [UpgradeWizard] - modules/jjwg_Maps/DataTables/media/js/jquery.js
Fri, 17 Nov 2023 14:55:02 -0500 [UpgradeWizard] - modules/jjwg_Maps/javascript/jquery-1.8.0.min.js

Does it ‘appear’ that it actually ‘finished’ the upgrade??
Any thoughts on getting the diagnostic tool to work??
(I’m wondering if it’s a symptom of the same issue???)

Any thoughts/help??
Thanks all!!!

Hi @TobyTkd

That uppgrade path seems to cause many people problems:

diagnostic tool will not run…

NB - @g.martin - Gillian -this looks like another occassion when @pgr’s Improved diagnostics #8686 PR could help

That is bad sounds like wrong permissions is worth ruling out.

I ‘believe’ I have the permissions and owners right?

It makes it much easier for people reading who may be able to help you, if you include more details in your post when asking for help.

EG here = what have you done to re-set your permissions this week - tell us the readers: have you followed the specific permissions guidance? Show us the page that tells you what to do with permissions -or copy here the exact command line work you did.

fair number (190 or so) “Account” records seems to ‘not’ have Email1 addressed any more

Tell us the readers - how many Accounts did NOT suffer that problem (eg is 190 only 0.1% of your database…or what: that is helpful for diagnosing)

Tell us what else you have tried

Eg - show us any Forum posts here that are on similar problems: and did you try the solutions -and did they work?

Your situation maybe a very quick fix - or tricky: its not clear yet. Hopefully quick :slight_smile:

DJUser –

PS - A message for everyone posting Help Requests here (not aimed at you TobyTkd)
In general the advice would be that a Request for Help will get quicker and better help, if the person can show that

  • they tried to fix it themselves (not just a lazy person who did not bother to google first!)
  • shows the things they tried that did not work: to stop helpers suggesting things that are immediately rejected with ‘I tried that already’: which makes the helper feel like they wasted their time.

Yes…I 100% agree with that you area saying.

In fact, I’d edited this post many times as I was diagnosing, and realize now that it’s all jacked up…heh.
My Bad!!

I’ve solved the issue with the email relationships missing. I have a script that caused the issue, and deployed the fix. Did NOT seem to be related to the upgrade.
Turns out, I had the SAME issue a few months ago, and ya’ll helped me solve.

I also solved some Linux module issues I caused while upgrading from 18 to 20.

So, now, I’m only left with 2 concerns:

1 - Did the “upgrade” seem to ‘finish’ based on the log above, or is it possible that there was some issue that might cause problems moving forward? I’m not sure how to ‘verify’ if everything is ok…or if there may be something missing in the log, that might point me at potential issues?

2 - the issue where the “Diagnostic Tool” will not run. Seems to hang at 0%. I’m ‘worried’ that perhaps the upgrade failure caused the issue…but not sure.

When I run it, I get no errors in the console, and there seem not to be any errors in the log.

I’ve set the file and folder permissions thusly:
sudo chown -R www-data:www-data .
sudo chmod -R 755 .
sudo chmod -R 775 cache custom modules themes data upload
sudo chmod 775 config_override.php 2>/dev/null

I turned on Debug, and found this, seemingly bad, line in there:
Wed Nov 22 15:42:46 2023 [2363][-none-][DEBUG] Unable to find SugarController:: Diagnostic

Here are some surrounding lines:

Wed Nov 22 15:42:46 2023 [2363][-none-][INFO] Query Execution Time:0.0001380443572998
Wed Nov 22 15:42:46 2023 [2363][-none-][DEBUG] Hook called: ::after_entry_point
Wed Nov 22 15:42:46 2023 [2363][-none-][DEBUG] Including module specific hook file for custom/modules
Wed Nov 22 15:42:46 2023 [2363][-none-][DEBUG] Including Ext hook file for custom/application
Wed Nov 22 15:42:46 2023 [2363][-none-][DEBUG] Hook called: ::after_session_start
Wed Nov 22 15:42:46 2023 [2363][-none-][DEBUG] Unable to find SugarController:: Diagnostic
Wed Nov 22 15:42:46 2023 [2363][-none-][DEBUG] We have an authenticated user id: 1
Wed Nov 22 15:42:46 2023 [2363][-none-][DEBUG] Hook called: Users::before_retrieve
Wed Nov 22 15:42:46 2023 [2363][-none-][DEBUG] Including module specific hook file for custom/modules/Users
Wed Nov 22 15:42:46 2023 [2363][-none-][DEBUG] Retrieve User : SELECT users.* FROM users  WHERE users.id = '1' AND users.deleted=0
Wed Nov 22 15:42:46 2023 [2363][-none-][DEBUG] Limit Query:SELECT users.* FROM users  WHERE users.id = '1' AND users.deleted=0 Start: 0 count: 1
Wed Nov 22 15:42:46 2023 [2363][-none-][INFO] Query:SELECT users.* FROM users  WHERE users.id = '1' AND users.deleted=0 LIMIT 0,1
Wed Nov 22 15:42:46 2023 [2363][-none-][INFO] Query Execution Time:0.00022292137145996
Wed Nov 22 15:42:46 2023 [2363][1][DEBUG] get_user_array query: SELECT id, first_name, last_name, user_name FROM users WHERE 1=1 ORDER BY first_name, last_name ASC
Wed Nov 22 15:42:46 2023 [2363][1][INFO] Query:SELECT id, first_name, last_name, user_name FROM users WHERE 1=1 ORDER BY first_name, last_name ASC
Wed Nov 22 15:42:46 2023 [2363][1][INFO] Query Execution Time:0.00017881393432617
Wed Nov 22 15:42:46 2023 [2363][1][INFO] Query:SELECT u1.first_name, u1.last_name from users  u1, users  u2 where u1.id = u2.reports_to_id AND u2.id = '1' and u1.deleted=0
Wed Nov 22 15:42:46 2023 [2363][1][INFO] Query Execution Time:0.00015592575073242
Wed Nov 22 15:42:46 2023 [2363][1][DEBUG] SugarBean[User].load_relationships, Loading relationship (reports_to_link).

Is this at all helpful??

Are you sure that is the username of the process running your Suite? Ie the web process.

To check: Under Linux - where it is the UID that matters not the user name (especially if you use eg Docker and have your suite file-system on the Host mounted as a Volume so the Guest can use it.

In your file-system (ie Host of the volume): this will show you the UID of the user

  • id -u

IE: to check the UID number of the user name you gave above: www-data

  • id -s www-data

Which needs to be compared to the UID of the process actually running suite - (which in Docker will be on a Guest container - so get a bash CLI in that container first)

  • ps -fe
    will show the name of the users running the processes. In our case the process we are looking at will be apache2 or nginx or etc

and

  • ps -fe n
    will show the UID -so you can match to the ‘id -u www-data’ we did above.

They must Match!

1 Like

Regarding the diagnostic error, what do you have in your after_session_start logic hook? I see that in the logs right before the diagnostic message.

Also, when trying to run the diagnostic tool, you can try clearing all checkboxes except one, and see if it runs. Then try different tests with different options turned on, so you can zoom in one which one is hanging.

Ok…so this is quire embarrassing.

I didn’t even see the ‘checkboxes’ on the right of the page, and it turns out that NONE were selected.
The theme we’re using makes those boxes quite ‘light’ in color, and way over on the right side of the page, so I didn’t even see them!

I check them 1 at a time, and all diagnostics ran fine.
Then I checked them all, and they all ran fine.

All seems well…
Thanks for the nudge in the right direction!

(Sheepishly closing the issue*)

2 Likes