danaenz

An update to mine - nginx was caching json requests strongly

Admonish

Hmm, I just went through my error logs and found that this was triggered at some point today.

  1. Uncaught Exception PDOException: "
  2. SQLSTATE[HY000] [2002] No such file or directory" at /home/path/vendor/silverstripe/framework/src/ORM/Connect/PDOConnector.php line
  3. 207 {"exception":"[object] (PDOException(code: 2002): SQLSTATE[HY000] [2
  4. 002] No such file or directory at /home/path/vendor/silver
  5. stripe/framework/src/ORM/Connect/PDOConnector.php:207)"} []

Anyone know what could have triggered this?

guttmann

looks like an issue during database build so potentially the database is unavailable in the CI environment?

🤔 (1)
jakx

I debugged this with a dev/build and the build went smoothly

guttmann

if you have access to edit vendor/silverstripe/framework/src/ORM/Connect/TempDatabase.php in the CI environment you could log the details of the exception that is being thrown to cause it to attempt to run the db build again and again which might give you some more useful information

👍 (1)
guttmann

This is the problem block:

  1. try {
  2. $this->rebuildTables($extraDataObjects);
  3. } catch (DatabaseException $ex) {
  4. // In case of error during build force a hard reset
  5. // e.g. pgsql doesn't allow schema updates inside transactions
  6. $this->kill();
  7. $this->build();
  8. $this->rebuildTables($extraDataObjects);
  9. }
firesphere

Yes, don't edit that, your problem is that the test database is build improperly due to a missing flush. easiest solution is to delete and recreate the silverstripe-cache folder right before you run your unit tests

👍 (1)
firesphere

That catch catches an actual database exception, namely table name too long. Removing the catch will only cause you more pain. Plus, editing the core tmp database class is not something that would work on a proper CircleCI build

guttmann

maybe I should have clarified I meant edit it for debugging purposes...

jakx

@guttmann was just suggesting to run some diagnostics, not subvert existing behaviour. I'll look into the cache 😃

firesphere

I promise you it's the cache... you're not the first. I spent a whole day debugging this, only to find I had to add flush=all to my phpunit command 😂

😂 (1)
firesphere

Vendor/bin/phpunit app/tests/folder flush=all

👍 (1)
jakx

@firesphere do you happen to know how to express that in a phpunit.xml configuration?

jakx
  1. <testsuites>
  2. <testsuite name="Default">
  3. <directory>app/tests</directory>
  4. </testsuite>
  5. </testsuites>
guttmann
  1. <phpunit>
  2. <php>
  3. <get name="flush" value="all" />
  4. </php>
  5.  
  6. </phpunit>
🙏 (1)

Show less replies
jakx

Running Circle CI, and my tests get stuck in a loop

  1. /root/project/vendor/silverstripe/framework/src/ORM/Connect/DBSchemaManager.php:161
  2. /root/project/vendor/silverstripe/framework/src/ORM/Connect/TempDatabase.php:246
  3. /root/project/vendor/silverstripe/framework/src/ORM/Connect/TempDatabase.php:283
  4. /root/project/vendor/silverstripe/framework/src/ORM/Connect/TempDatabase.php:192
  5. /root/project/vendor/silverstripe/framework/src/ORM/Connect/TempDatabase.php:288
  6. /root/project/vendor/silverstripe/framework/src/ORM/Connect/TempDatabase.php:192
  7. /root/project/vendor/silverstripe/framework/src/ORM/Connect/TempDatabase.php:288
  8. ...

Is there an obvious cause here?

firesphere

Yes, the cause is SilverStripe switching to a non-flushed php unit test suite by default between 4.2 and 4.3... this causes your flush without test classes to run, and PHPUnit trying to use this cache. Which means, the PHPUnit test doesn't know about the implements TestOnly table names

👍 (1)
danaenz
  1. NextID: null
  2. ParentID: "6"
  3. PrevID: 22

vs

  1. NextID: 18
  2. ParentID: "6"
  3. PrevID: null

The second example seeming to "snap" back to the original position

danaenz

So the XHR request goes: admin/pages/edit/updatetreenodes?ids=13 It sometimes passes PrevID and sometimes PrevID is blank