Missing path attribute

This reminds me of #3012019: Include the path / url alias. Over there, the root cause was #3012019-11: Include the path / url alias:

It was a translation issue in combination with a base field override..

Perhaps that's also what's going on with your site?

Ironically, that was reported by a former colleague of yours :D

Your screenshot got me thinking. I did some searching. It seems #2511968: Path field should fall back to language neutral aliases (also makes this happen for the form widget!) would give you the behavior you were expecting.

I quoted the clue in #2, but I realize it’s still pretty vague. So let’s make it more concrete.

I strongly suspect that your problem is that the entity with the “missing” path attribute actually has a path alias with a langcode that is different from the entity’s langcode. I bet that making it match will result in it showing up!

Also: please update to RC2!

Updating the module didn't bring any changes on this.

I did not expect it to, but thanks for confirming! 🙏

Okay, I tried reverse engineering the content types and re-creating the issue, where's what I got:

1. By using the entity_clone module I duplicated one of the faulty content types => it didn't show the path same way the original content type didn't.
   Then I went and deleted every single field from the duplicated content type (to check if another field might be causing issues) 1 by 1. After having no fields left in the entity there was still no path property to be seen.
2. Then I tried the opposite - creating a new content type from scratch and reuse all of the same fields that the faulty content type had => but the path was still showing.
3. Between those actions there were plenty of cache clears and even some pathauto regenerations.. No change.

During the last testing I remembered that on updating Drupal core (8.5 => 8.6) there were configurations (after drush updb) that were lost (drush updb + instantly drush cim after updating core) although there should've been an export after updating the database.
But I'm not sure if it has anything to do with this issue, though, as some of the old content types also display path fine.

Also, could it really have something to do with the database if creating an identical content type which reuses the exact same fields (that are used by the broken content type) work fine?

I've had similar issues, but I don't think it is actually jsonapi's fault. Seems to be a core bug. I've noticed that if I inspect the load tab in devel $node->path is missing there as well. Steps to reproduce are pretty simple:
1. New d8 standard install.
2. Create an article and page with alias.
Path will show in devel tab.
3. Enabled content translation and enable it for those content types.
Path will disappear in devel tab. Seems to be a permanent buggy state. Simply disabling translation will have no effect.

I wasn't able to get rid of this bug til I did hard uninstalls of all translations modules, deleted all aliases, and did a hard uninstalled the path module itself (do not remember that being an easy process).

Could you both apply the latest patch at #2511968: Path field should fall back to language neutral aliases (also makes this happen for the form widget!) and report back?

Nick, you're pretty spot on with your thought.
We found out that this issue occurred to only few old content types (new/healthy copies of content types always had the path attribute). David[corbacho] took notice of your 'base field override' suggestion, Wim, and run into https://drupal.stackexchange.com/questions/271598/how-to-remove-base-field-overrides where he found drush config:delete core.base_field_override.node.[Problematic_ContentType].path which then deleted the config for [Problematic_ContentType].path.yml file and path attribute showed up once again after a cache clear.
Apparently there were some of "empty looking" overrides left in the configs. I'm not sure how those configs got created one/two years ago from exporting production content.. but they apparently did.
Added a screenshot where we see the faulty config that doesn't even have any callbacks. Either way - removing the faulty config ( Problematic_ContentType.path.yml) did the trick and we're able to access our beloved url alias once again! :)

I'm glad that you've been able to confirm it had the same root cause as #3012019: Include the path / url alias, but you both explained it much more clearly!

Also, #2511968: Path field should fall back to language neutral aliases (also makes this happen for the form widget!) landed! I suspect (I'm not certain since I haven't gone through all the steps listed to reproduce it, which I'd need to do to be able to step through it with a debugger to be 100% certain) that that will actually also prevent this problem.

#3012019 was definitely the same issue (it was fixed on fresh install!). I'll give #2511968 a test tomorrow... The database tables have actually behaved really well in my tests... I think Phonoman hit on the head... it's not a database problem... It's a config issue. This is why my hard reinstalls fixed it. This is maybe why #3012019 was fixed on fresh install? One thing I do know is that I was able to fix it by creating a new custom computed field on an existing site. The same module fails just as path would on a new site.

#13 was lifesaver. Thank you Phonoman

Deleting the core.base_field_override.*.yml config make sense only if the field is not actually overridden. If anyone faces the missing path issue and needs to keep the field properties overridden, please try the patch at https://www.drupal.org/project/drupal/issues/3274419 and let me know whether it helps.