500: ($company_token) must be of type App\Models\CompanyToken, null given

Hello!

I’m trying to migrate our v5.5.70 to v5.6.28. I know, I know, it’s a bit old, but bear with me.

I set up the newer version fresh via git clone and typical installation steps and the React front end and that all worked fine.

Now for the data. I have ~40,000 invoices on the old version (which Flutter doesn’t like) and that makes the standard export feature not work so well with PHP timing out. So I did a mysql export of just the data in hopes of importing it into the new one. It mostly went well, with some hiccups with an index and migrations and invalid MAC (sync the APP_KEYs).

Now when I go to log in, I receive this 500 error:

production.ERROR: App\Transformers\CompanyTokenTransformer::transform(): Argument #1 ($company_token) must be of type App\Models\CompanyToken, null given, called in /usr/share/nginx/invoiceninja-test/vendor/league/fractal/src/Scope.php on line 407 {“userId”:1,“exception”:"[object] (TypeError(code: 0): App\Transformers\CompanyTokenTransformer::transform(): Argument #1 ($company_token) must be of type App\Models\CompanyToken, null given, called in /usr/share/nginx/invoiceninja-test.iitechno.com/vendor/league/fractal/src/Scope.php on line 407 at /usr/share/nginx/invoiceninja-test.iitechno.com/app/Transformers/CompanyTokenTransformer.php:41)

Chasing down the stack, if transform() is getting null, I can’t follow much further on where it’s coming from in the myriad of /vendor files.

Versions aside, what could be the suspects here? I’ve been pulling my hair out for days on this.

Thank you!

Hi,

It sounds like the database may not have copied over correctly, I suggest trying again using mysqldump.

Sadly, no luck. I’ve since:

Set up the newer version. Again, works on it’s own.
Did a DB copy by doing:

mysqladmin -u root create invoiceninja-test
mysqldump invoiceninja | mysql invoiceninja -test

Adjusted the .env to use this new DB and match the APP_KEY of the original invoiceninja install

And it just refuses to let me log in, citing the same error.

Is there anything related that I could trial-and-error? Are there consequences to clearing out the company_tokens table? Are there any related objects that I should suspect? Should I double-check the company_tokens-related migrations to make sure they were implemented?

Thanks!

I believe I have this figured out. In the company_tokens table, there is an is_system field. It seems to be treated as boolean.

As a web client/user on v5.5.70, it doesn’t seem to care that is_system is 0. It still logs me in.

As a web client/user on v5.6.28, it seems to care more about that setting. Changing it a 1 on the record aligned to my user_id and company_id allowed me to finally log in.

While the data being brought over was identical, I can only presume there was a change in some logic between those versions. Hopefully this helps someone else!

Glad to hear it, thanks for the update!

cc @david