Looks like my screenshot link doesn't work. Trying to attach it here again.

I can confirm notice in update from 3.5.1 to 3.7.0Rc1

Notice: Undefined property: stdClass::$client_id in /opt/lampp/htdocs/Joomla_3.5.1-Stable-Full_Package/libraries/vendor/joomla/utilities/src/ArrayHelper.php on line 521

Notice: Undefined property: stdClass::$client_id in /opt/lampp/htdocs/Joomla_3.5.1-Stable-Full_Package/libraries/vendor/joomla/utilities/src/ArrayHelper.php on line 522

Notice: Undefined property: stdClass::$client_id in /opt/lampp/htdocs/Joomla_3.5.1-Stable-Full_Package/administrator/modules/mod_menu/preset/enabled.php on line 200

Notice: Undefined property: stdClass::$client_id in /opt/lampp/htdocs/Joomla_3.5.1-Stable-Full_Package/administrator/modules/mod_menu/preset/enabled.php on line 200

I did not get that with php 5.4.4

I can confirm same notice also from Joomla 3.4.8 --> 3.7.0Rc1 from Isis admin template.
php 5.5.15
After confirming update by login it is ok

The only reason i could imagin is that the file replace are done (new files are there) but not the database changes. Maybe @izharaazmi can come up with a solution where we make sure that the client id is checked on existens before it is used in the new code.

I could not reproduce this issue.
Installed fresh joomla 3.6.5 and updated to 3.7.0 rc1.
Created an administrator menu site menu and navigated accross the backend ,evrything works fine.

please try also from 3.4.8 --> 3.7.0Rc1 and from 3.5.1 --> 3.7.0Rc1

As far I understand this issue can only come up when updating from
3.7-alpha1. Not before not after that. Please whoever is facing this
issue, test again with a clean install.

@izharaazmi it is not that simple ;) The problem is the update prozess ;)

At that place where the issue comes up the database changes are not run yet but the new files are placed. So it means we run the new code on the old database structure (without client_id)
Because of a change in the updater code you need to take this step between the update (before the database but after file replace) if you come from a older version than 3.6.x so you can reproduce that with error reporting to max and a starting version like 3.4.8 or 3.5.1 but not 3.6.5 as this step is not needed if you come from that version ;)

The problem shows up because the mod_menu is used also on this page so the new code needs also work without the database change maybe just fallback to the system preset menu if possibel ;)

Wow! Correct! I'd look at this. Thanks @zero-24

This screen is displayed on updating Joomla 3.5.1 to 3.7.0rc1.

This is a confirmation which is asked before updating database but after copying the files.Therefore it doesn`t make sense as it should ask confirmation before even copying files.

@Gitjk it is not about asking for update. that was done with the hit on the install button.

As explained above this comes because of a change in the code of com_joomlaupdate were the old code is triggering the new code. As the old code does not include the sec token the new code could fail (no sec code) -> die('Some random message') or it just let the user re confirm the pw.

We have done the seccond. you may also notice that this message comes up only one time. If do any later update this message does not come up.

The change from the old code to the new code is happening if the updater did replace the old code by the new but the database changes are not done yet.

even the die way would leave the database untouched and the new code needs to perform with the old database.

The easyiest fix would be to make the new mod_menu able to be used with and without client ID. and if there is none just fallback to the system preset.

@zero-24 Exactly! I wonder about the same thing that why we are moving in
the new files before the confirmation page? Can't we hold it until
confirmation and process files+database together?

This is not just about mod_menu (this is just the current case). This may
happen whenever a new code tries to access old db when executed during this
update confirmation page display.

Saddly not. As after we have patched the files the code needs to give over to the new code (as the old was just replaced) and the new code checks for a token the old code can never provide. ;) So we can die here or ask the user to re enter the PW and than move over.

happen whenever a new code tries to access old db when executed during this
update confirmation page display.

Correct.

I'd try to come up with a solution tomorrow hopefully. What it looks like
right now, should not be true. :)

just remember you can't change the source as we cant time travel. The call will always be without the token and for the new code and sec reasons this is invalid.

Sure.

One more thing that bugs me now is that –

1. What if user fails to provide password or navigates away from that page?
   Files are still already updated. Db is not. Fail?
2. What if user cannot provide password (he doesn't know it) but navigates
   to database fix pages and can do it from there. Right?

1. What if user fails to provide password or navigates away from that page?
   Files are still already updated. Db is not. Fail?

Correct

2. What if user cannot provide password (he doesn't know it) but navigates
   to database fix pages and can do it from there. Right?

Correct too.

So does this mean the confirmation page is needless? Or I'm missing
something?

It's needed to deal with a scenario where the upgrade fails the CSRF token check. So for newer versions you won't hit it, but anything 3.6.0 and earlier upgrading will unless you update the update component first. Unfortunately that does mean that the site is in a "mixed" state but unless the entire upgrade process is rewritten in a way where these steps aren't performed by the main Joomla application this is what we're stuck with.

That sounds like a good direction. I'll think more over it. Come up with
something nice hopefully.

The issue here with older J version (here a 3.4.5 one is that one has to click Twice on the Confirm button to finish up the process.

I can confirm same notice and error also from Joomla 3.4.8 or 3.5.1 --> 3.7.0Rc2

also Notice: Undefined property: stdClass::$readonly in /opt/lampp/htdocs/Joomla_3.5.1-Stable-Full_Package/layouts/joomla/tinymce/textarea.php on line 22
when try to create a new category after update from 3.5.1 --> 3.7.0Rc2

Please create a new issue for that. This looks like a different issue to me.

done: #15243

Closing as there is a PR #15275