Upgrade to 1.3.0 not working

[SLiCK_303]

stuck on one of the first steps....doesnt go any further....

edit: posted this in the wrong place..sorry.  feel free to move it if you like....

edit2: so I deleted my cache folder, and re-uploaded a fresh copy.  I also tried using a different browser to do the update, still no go, stuck at the same %.

edit3: tried on my clone site, same thing, stuck at 42.86%....

Edited October 19, 2021 by SLiCK_303

[SLiCK_303]

trying to open up the core updater log file, to see if it says anything useful.  I'ts like almost 3 gigs.....little carried away with the loggin aren't cha?

edit: ok so I deleted the log file, and ran the updater again.  The last three lines of my log are....

2021-10-18 21:49:56 Process cabb65ede725607d9aa5302df99efbb5: step DOWNLOAD_FILES finished with state {"progress":1,"state":"DONE"}
2021-10-18 21:49:56 Process cabb65ede725607d9aa5302df99efbb5: processing step {"action":"DOWNLOAD_FILES","revision":"1.2.0","ignoreTheme":false}
2021-10-18 21:49:56 API request: {"revision":"1.2.0","action":"list-revision","php":"7.4.24"}

 

Edited October 19, 2021 by SLiCK_303

[datakick]

4 hours ago, SLiCK_303 said:

trying to open up the core updater log file, to see if it says anything useful.  I'ts like almost 3 gigs.....little carried away with the loggin aren't cha?

 

definitely not 3 gigs, maybe 3 megs. But you are correct, we log too much. I've released new version of core updater with optimised logging.

4 hours ago, SLiCK_303 said:

2021-10-18 21:49:56 Process cabb65ede725607d9aa5302df99efbb5: step DOWNLOAD_FILES finished with state {"progress":1,"state":"DONE"}
2021-10-18 21:49:56 Process cabb65ede725607d9aa5302df99efbb5: processing step {"action":"DOWNLOAD_FILES","revision":"1.2.0","ignoreTheme":false}
2021-10-18 21:49:56 API request: {"revision":"1.2.0","action":"list-revision","php":"7.4.24"}

Looks like the the API request didn't finish for some reason. This is server-server communication, so definitely not browser issue. Maybe you have some sort of antivirus / security software installed on your server?

[Vajenec]

I have different problem....

chunk-0001.tar.gz is invalid Unable to open in read mode

[datakick]

22 minutes ago, Vajenec said:

I have different problem....

chunk-0001.tar.gz is invalid Unable to open in read mode

Install new version of core updater 1.4.3 and try again. 

[Vajenec]

13 minutes ago, datakick said:

Install new version of core updater 1.4.3 and try again. 

Thanks, now is OK.

[musicmaster]

4 hours ago, datakick said:

definitely not 3 gigs, maybe 3 megs. But you are correct, we log too much. I've released new version of core updater with optimised logging.

Looks like the the API request didn't finish for some reason. This is server-server communication, so definitely not browser issue. Maybe you have some sort of antivirus / security software installed on your server?

When you asked for feedback about the Core Updater I reported too that it remained stuck at 42.86%. There was never a report that that was solved. I just checked for the log files from those tests: 4.3 and 8.9 GB. So Slick_303 is right.

By doing a new "upgrade" that I broke off almost immediately after it got stuck at 42.86 I managed to get a shorter log file. I have it attached

coreupdater-20211019.log

[datakick]

10 minutes ago, musicmaster said:

When you asked for feedback about the Core Updater I reported too that it remained stuck at 42.86%. There was never a report that that was solved. I just checked for the log files from those tests: 4.3 and 8.9 GB. So Slick_303 is right.

By doing a new "upgrade" that I broke off almost immediately after it got stuck at 42.86 I managed to get a shorter log file. I have it attached

coreupdater-20211019.log 46.07 MB · 0 downloads

From server log I can see that some clients requests file list over and over again. Looks like the client fails to store the file list to cache. At least thats the only explanation I could came with. This is (hopefully) fixed in latest version of the module. Are you using 1.4.3?

Edit: From your log it's evident you are using 1.4.0. Please update core updater module. BTW, what mysql version are you using? 

[musicmaster]

Updating indeed allowed it to go further. Thank you.

The database software is MariaDB 10.4.8

[musicmaster]

One little other thing: the modified files. It seems to me extremely unlikely I changed all these files. Maybe one or two, but my impression is that most were changed in some system operation.

[datakick]

30 minutes ago, musicmaster said:

One little other thing: the modified files. It seems to me extremely unlikely I changed all these files. Maybe one or two, but my impression is that most were changed in some system operation.

I believe you were on some bleeding edge version before?

If that's the case, then rest assured -- this is the one-time issue only. Next update will not be affected.

When updating to bleeding edge we didn't actually saved exact git revision that was being used. In your store the only available information was that this is some variant of 1.2.0. Not very useful. 

During update, core updater asked server for a fingerprints of files for version '1.2.0', and checks it agains files on your server. Of course, every files that were modified between 1.2.0 and the bleeding edge version you have on your store will have different fingerprint, and so they will be considered modified.

The new core updater fixes this issue -- we now define new constant _TB_REVISION_ that points to exact git revision or tag. During update, core updater will ask for fingerprints of files for this exact revision. 

[musicmaster]

24 minutes ago, datakick said:

I believe you were on some bleeding edge version before?

If that's the case, then rest assured -- this is the one-time issue only. Next update will not be affected.

When updating to bleeding edge we didn't actually saved exact git revision that was being used. In your store the only available information was that this is some variant of 1.2.0. Not very useful. 

During update, core updater asked server for a fingerprints of files for version '1.2.0', and checks it agains files on your server. Of course, every files that were modified between 1.2.0 and the bleeding edge version you have on your store will have different fingerprint, and so they will be considered modified.

The new core updater fixes this issue -- we now define new constant _TB_REVISION_ that points to exact git revision or tag. During update, core updater will ask for fingerprints of files for this exact revision. 

Isn't it possible to use normal subversions instead of revisions? Like 1.03.01 and 1.03.02?

[datakick]

5 minutes ago, musicmaster said:

Isn't it possible to use normal subversions instead of revisions? Like 1.03.01 and 1.03.02?

Why?

For people that will use Stable releases this is not an issue. The revisions will always match official release tags, such as 1.3.0 or 1.2.0.

If you are using bleeding edge, then you will see current exact git commit. This information for machines, not for humans. Revision is precise and it nicely correlates with information on github.

I understand that from human point of view, it's nicer to see 1.4.134 instead of d601a7dfa69025341ea598f558885b6cbbd7b7b4. However, nobody would be able to figure out what exactly is part of version 1.4.134, or what are the differences between 1.3.0 and 1.4.134, simply because 1.4.134 would not tracked in repository. 

With revisions, we can look at github and see it all. 

What is part of this version? https://github.com/thirtybees/thirtybees/tree/d601a7dfa69025341ea598f558885b6cbbd7b7b4

What are the differences between 1.3.0 and current bleeding edge? https://github.com/thirtybees/thirtybees/compare/1.3.0...d601a7dfa69025341ea598f558885b6cbbd7b7b4 

 

[musicmaster]

14 minutes ago, datakick said:

Why?

For people that will use Stable releases this is not an issue. The revisions will always match official release tags, such as 1.3.0 or 1.2.0.

If you are using bleeding edge, then you will see current exact git commit. This information for machines, not for humans. Revision is precise and it nicely correlates with information on github.

I understand that from human point of view, it's nicer to see 1.4.134 instead of d601a7dfa69025341ea598f558885b6cbbd7b7b4. However, nobody would be able to figure out what exactly is part of version 1.4.134, or what are the differences between 1.3.0 and 1.4.134, simply because 1.4.134 would not tracked in repository. 

With revisions, we can look at github and see it all. 

What is part of this version? https://github.com/thirtybees/thirtybees/tree/d601a7dfa69025341ea598f558885b6cbbd7b7b4

What are the differences between 1.3.0 and current bleeding edge? https://github.com/thirtybees/thirtybees/compare/1.3.0...d601a7dfa69025341ea598f558885b6cbbd7b7b4 

 

Experience learns that even minor revisions can bring errors. So when someone reports an error it is always good to know exactly what version he used. You cannot ask someone to have a look in his database for what _TB_REVISION_ he has.

[jmeca]

problems after upgrade Core Updater:

Transport exception

Detalles

GuzzleHttp\Exception\RequestException: cURL error 60: SSL certificate problem: certificate has expired (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) in /home/www/xxxxxxxxxxxxx/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:201

[jmeca]

Just now, jmeca said:

problems after upgrade Core Updater:

Transport exception

Detalles

GuzzleHttp\Exception\RequestException: cURL error 60: SSL certificate problem: certificate has expired (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) in /home/www/xxxxxxxxxxxxx/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:201

Any help please

[jmeca]

This is the full error:

GuzzleHttp\Exception\RequestException: cURL error 60: SSL certificate problem: certificate has expired (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) in /home/www/xxxxxxxxxxxxxx.00/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:201
Stack trace:
#0 /home/www/xxxxxxxxxxxxxx.00/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(155): GuzzleHttp\Handler\CurlFactory::createRejection(Object(GuzzleHttp\Handler\EasyHandle), Array)
#1 /home/www/xxxxxxxxxxxxxx.00/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(105): GuzzleHttp\Handler\CurlFactory::finishError(Object(GuzzleHttp\Handler\CurlHandler), Object(GuzzleHttp\Handler\EasyHandle), Object(GuzzleHttp\Handler\CurlFactory))
#2 /home/www/xxxxxxxxxxxxxx.00/vendor/guzzlehttp/guzzle/src/Handler/CurlHandler.php(43): GuzzleHttp\Handler\CurlFactory::finish(Object(GuzzleHttp\Handler\CurlHandler), Object(GuzzleHttp\Handler\EasyHandle), Object(GuzzleHttp\Handler\CurlFactory))
#3 /home/www/xxxxxxxxxxxxxx.00/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php(28): GuzzleHttp\Handler\CurlHandler->__invoke(Object(GuzzleHttp\Psr7\Request), Array)
#4 /home/www/xxxxxxxxxxxxxx.00/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php(51): GuzzleHttp\Handler\Proxy::GuzzleHttp\Handler\{closure}(Object(GuzzleHttp\Psr7\Request), Array)
#5 /home/www/xxxxxxxxxxxxxx.00/vendor/guzzlehttp/guzzle/src/PrepareBodyMiddleware.php(66): GuzzleHttp\Handler\Proxy::GuzzleHttp\Handler\{closure}(Object(GuzzleHttp\Psr7\Request), Array)
#6 /home/www/xxxxxxxxxxxxxx.00/vendor/guzzlehttp/guzzle/src/Middleware.php(29): GuzzleHttp\PrepareBodyMiddleware->__invoke(Object(GuzzleHttp\Psr7\Request), Array)
#7 /home/www/xxxxxxxxxxxxxx.00/vendor/guzzlehttp/guzzle/src/RedirectMiddleware.php(70): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Request), Array)
#8 /home/www/xxxxxxxxxxxxxx.00/vendor/guzzlehttp/guzzle/src/Middleware.php(57): GuzzleHttp\RedirectMiddleware->__invoke(Object(GuzzleHttp\Psr7\Request), Array)
#9 /home/www/xxxxxxxxxxxxxx.00/vendor/guzzlehttp/guzzle/src/HandlerStack.php(71): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Request), Array)
#10 /home/www/xxxxxxxxxxxxxx.00/vendor/guzzlehttp/guzzle/src/Client.php(351): GuzzleHttp\HandlerStack->__invoke(Object(GuzzleHttp\Psr7\Request), Array)
#11 /home/www/xxxxxxxxxxxxxx.00/vendor/guzzlehttp/guzzle/src/Client.php(162): GuzzleHttp\Client->transfer(Object(GuzzleHttp\Psr7\Request), Array)
#12 /home/www/xxxxxxxxxxxxxx.00/vendor/guzzlehttp/guzzle/src/Client.php(182): GuzzleHttp\Client->requestAsync('post', Object(GuzzleHttp\Psr7\Uri), Array)
#13 /home/www/xxxxxxxxxxxxxx.00/vendor/guzzlehttp/guzzle/src/Client.php(95): GuzzleHttp\Client->request('post', '/coreupdater/v2...', Array)
#14 /home/www/xxxxxxxxxxxxxx.00/modules/coreupdater/classes/api/ThirtybeesApiGuzzle.php(258): GuzzleHttp\Client->__call('post', Array)
#15 /home/www/xxxxxxxxxxxxxx.00/modules/coreupdater/classes/api/ThirtybeesApiGuzzle.php(245): CoreUpdater\Api\ThirtybeesApiGuzzle->performPost(Array)
#16 /home/www/xxxxxxxxxxxxxx.00/modules/coreupdater/classes/api/ThirtybeesApiGuzzle.php(221): CoreUpdater\Api\ThirtybeesApiGuzzle->callApi('check-module-ve...', Array)
#17 /home/www/xxxxxxxxxxxxxx.00/modules/coreupdater/controllers/admin/AdminCoreUpdaterController.php(847): CoreUpdater\Api\ThirtybeesApiGuzzle->checkModuleVersion('1.4.3')
#18 /home/www/xxxxxxxxxxxxxx.00/modules/coreupdater/controllers/admin/AdminCoreUpdaterController.php(345): AdminCoreUpdaterController->checkModuleVersion()
#19 [internal function]: AdminCoreUpdaterController->performInitContent()
#20 /home/www/xxxxxxxxxxxxxx.00/modules/coreupdater/classes/ErrorHandler.php(56): call_user_func_array(Array, Array)
#21 /home/www/xxxxxxxxxxxxxx.00/modules/coreupdater/controllers/admin/AdminCoreUpdaterController.php(335): CoreUpdater\ErrorHandler->handleErrors(Array)
#22 /home/www/xxxxxxxxxxxxxx.00/classes/controller/Controller.php(208): AdminCoreUpdaterController->initContent()
#23 /home/www/xxxxxxxxxxxxxx.00/classes/Dispatcher.php(852): ControllerCore->run()
#24 /home/www/xxxxxxxxxxxxxx.00/jm3c4/index.php(63): DispatcherCore->dispatch()
#25 {main}

Next CoreUpdater\Api\ThirtybeesApiException: Transport exception in /home/www/xxxxxxxxxxxxxx.00/modules/coreupdater/classes/api/ThirtybeesApiGuzzle.php:262
Stack trace:
#0 /home/www/xxxxxxxxxxxxxx.00/modules/coreupdater/classes/api/ThirtybeesApiGuzzle.php(245): CoreUpdater\Api\ThirtybeesApiGuzzle->performPost(Array)
#1 /home/www/xxxxxxxxxxxxxx.00/modules/coreupdater/classes/api/ThirtybeesApiGuzzle.php(221): CoreUpdater\Api\ThirtybeesApiGuzzle->callApi('check-module-ve...', Array)
#2 /home/www/xxxxxxxxxxxxxx.00/modules/coreupdater/controllers/admin/AdminCoreUpdaterController.php(847): CoreUpdater\Api\ThirtybeesApiGuzzle->checkModuleVersion('1.4.3')
#3 /home/www/xxxxxxxxxxxxxx.00/modules/coreupdater/controllers/admin/AdminCoreUpdaterController.php(345): AdminCoreUpdaterController->checkModuleVersion()
#4 [internal function]: AdminCoreUpdaterController->performInitContent()
#5 /home/www/xxxxxxxxxxxxxx.00/modules/coreupdater/classes/ErrorHandler.php(56): call_user_func_array(Array, Array)
#6 /home/www/xxxxxxxxxxxxxx.00/modules/coreupdater/controllers/admin/AdminCoreUpdaterController.php(335): CoreUpdater\ErrorHandler->handleErrors(Array)
#7 /home/www/xxxxxxxxxxxxxx.00/classes/controller/Controller.php(208): AdminCoreUpdaterController->initContent()
#8 /home/www/xxxxxxxxxxxxxx.00/classes/Dispatcher.php(852): ControllerCore->run()
#9 /home/www/xxxxxxxxxxxxxx.00/jm3c4/index.php(63): DispatcherCore->dispatch()
#10 {main}

[datakick]

17 minutes ago, musicmaster said:

Experience learns that even minor revisions can bring errors. So when someone reports an error it is always good to know exactly what version he used. You cannot ask someone to have a look in his database for what _TB_REVISION_ he has.

Of course I can ask them to look into database 🙂 But fortunately I won't have to

[datakick]

20 minutes ago, jmeca said:

problems after upgrade Core Updater:

Transport exception

Detalles

GuzzleHttp\Exception\RequestException: cURL error 60: SSL certificate problem: certificate has expired (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) in /home/www/xxxxxxxxxxxxx/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:201

This is your server configuration problem. Certificate on api.thirtybees.com is valid and trusted:

Your server probably do not have updated trust stores / root certificates. You need to update your server packages. How to do that depends on your distribution. Some hints can be found for example here:

https://superuser.com/questions/1679204/curl-on-ubuntu-14-all-lets-encrypt-certificates-are-expired-error-60

 

[jmeca]

Of course I can ask them to look into database 🙂 But fortunately I won't have to

in what place of database i have to look?

[musicmaster]

8 minutes ago, datakick said:

Your server probably do not have updated trust stores / root certificates. You need to update your server packages. How to do that depends on your distribution. Some hints can be found for example here:

https://superuser.com/questions/1679204/curl-on-ubuntu-14-all-lets-encrypt-certificates-are-expired-error-60

 

Is this really necessary? I never before heard of a software package refusing installation because an expired certificate - a quite common problem.

[datakick]

7 minutes ago, musicmaster said:

Is this really necessary? I never before heard of a software package refusing installation because an expired certificate - a quite common problem.

Server certificate on api.thirtybees.com is not expired, it's completely valid.  

[musicmaster]

1 hour ago, datakick said:

Of course I can ask them to look into database 🙂 But fortunately I won't have to

The disadvantage is that only you will be capable of determining which revision is older and which is the latest. For almost everyone else it will be just too much effort.

[datakick]

@jmeca download this file: https://raw.githubusercontent.com/thirtybees/thirtybees/main/tools/cacert.pem and upload it to your thirty bees /tools/cacert.pem 

[the.rampage.rado]

@datakick, yesterday I put the new coreupdater on one of my shops just to check it and I failed to find the option where I was able to select which version to update/downgrade. I only see the two main channels.

I think this option was very nice and probably you should think of bringing it back. Soon or later it will save some merchant from module incompatibility or else.

 

Best regards for the great work! 😉

[datakick]

3 minutes ago, the.rampage.rado said:

@datakick, yesterday I put the new coreupdater on one of my shops just to check it and I failed to find the option where I was able to select which version to update/downgrade. I only see the two main channels.

I think this option was very nice and probably you should think of bringing it back. Soon or later it will save some merchant from module incompatibility or else.

Best regards for the great work! 😉

Yes, that's the advanced functionality that we plan to put back there in the future, very well hidden so that nobody will use it 😉