For the last couple of days I have started seeing this error in the javascript console. Uncaught (in promise) Error: Schema: Model 'taxonomy_term--plant_type' not defined. and if I try to open a plant in asset-link i get this error.
I also can’t search for a plant. I can’t say exactly when it started to happen but it might have been after updating to farmOS 3.2 but it might have been later as well.
I have tried to uninstalled and reinstalled asset-link to make sure it wasn’t any of my plugin and now even with non of my plugins added it still happen.
1 Like
@jorblad Did you update to farmOS 3.2.1 or 3.2.0. There was a bug discovered in 3.2.0 that broke taxonomy term JSON Schemas - which could explain what you’re seeing in Asset Link. This was fixed in 3.2.1 which was released two days later.
Here is the specific bug: Patch JSON:API Schema to fix Issue #3390505: Error: uri is not a valid type for a JSON document by mstenta · Pull Request #827 · farmOS/farmOS · GitHub
First 3.2.0 and this morning 3.2.1 but the problem appeared even after updating to 3.2.1.
1 Like
It’s also possible something got into a bad state and persisted in the browser storage - possibly due to that 3.2.0 bug that Mike mentioned or something else.
I haven’t updated to 3.2.x yet so there could be a new bug there for Asset Link specifically. I’ll have to try and test myself soon.
Have you tried clearing all local data in Asset Link? (Make sure to backup any locally modified plugin code and things like that so you don’t lose anything.)
Even if that fixes it, it’s likely there’s room for improvement here since ideally Asset Link should be able to recover on its own.
2 Likes
I have tried to clean multiple times bot to no avail. I only have my plugin hosted on github so they are safe 
Very curious if this is caused by 3.2.x update! Let me know if you pinpoint it @Symbioquine @jorblad!
I updated my development and production instances to 3.2.1 and so far haven’t encountered this. I haven’t tried taking an older version of my instance and updating it to 3.2.0 yet to see if the problem was specific to that upgrade path.
Can you maybe try a different browser (i.e. Chrome if you’re using Firefox or visa-versa), just as a sanity [mine] check?
Edge on android, edge on mac and firefox on mac is what I have tried and same problem on all of them…
I will also try to update to alpha 13 of asset-link, not that I think that will make much difference but will try anyway.
Hmmm, I’ve now tested against my development instance updating from 3.1.2 to 3.2.0 without encountering that problem.
Maybe you can provide the stacktrace from the javascript console?
1 Like
Now it was working on firefox and edge on android, will see how edge on mac will do.
1 Like
Even edge seems okey now after alpha13 and clear cache however when I wanted to add back some plugins this is what met me.
Lägg till Asset link standardplugin Jörblad Farm.pdf (628.7 KB)
I don’t know if it affects anything or not but it dosen’t quite looks right…
Edit: Not every time I try to add but the first time I clicked add new standardplugin from the list of plugins. When I did it again to add another plugin it didn’t show up.
Edit 2: And after I added one it shows up again I again get this.
1 Like
Okay, that’s interesting. The way Asset Link gets information about how data is structured in farmOS is running into an error - which would basically break Asset Link.
The code in question is here: https://github.com/symbioquine/farmOS_asset_link/blob/8abf89f326e16b2bd62b80fe67f24017f7b310b4/farmos_asset_link/src/Controller/FarmAssetLinkModelsController.php
The way it is supposed to work is that it loads the list of all schemas from /api/schema, then traverses the links from there to each schema collection/item, and finally returns all the leaf schemas (i.e. /api/asset_type/asset_type/resource/schema) as a big JSON object.
The warnings from your screenshot seem to suggest that the code doing the traversing is encountering something wildly different than it is expecting.
However, I took the liberty of loading your schemas from https://farm.jorblad.se/api/schema and they look normal to me.
That leaves me a bit stumped. Maybe there’s something wrong with the way I’m getting the schemas using the HTTP kernel subrequest functionality… Any ideas or troubleshooting tips @mstenta?
1 Like
Hmm @jorblad just to be sure: did you run drush updb and drush cr after updating to farmOS 3.2.0 and 3.2.1?
Yes that I have done a few times after the update.
Edit: After updating I always run this script
#!/bin/bash
# Hämta container ID för den körande containern
CONTAINER_ID=$(docker ps -qf "name=root_www_1")
# Kör kommandon i containern
#docker exec -it $CONTAINER_ID composer require 'drupal/openapi_jsonapi:^3.0'
docker exec -it $CONTAINER_ID composer require 'drupal/farm_ledger:^2.0'
docker exec -it $CONTAINER_ID composer require 'drupal/farm_project_plan:^1.0'
docker exec -it $CONTAINER_ID composer require 'drupal/farmos_asset_link:^1.0@alpha'
docker exec -it $CONTAINER_ID composer require 'drupal/smtp:^1.2'
docker exec -it $CONTAINER_ID composer require 'drupal/farm_asset_termination:^1.2'
docker exec -it $CONTAINER_ID composer require 'drupal/json_field:^1.2'
docker exec -it $CONTAINER_ID composer require 'drupal/gin_login'
docker exec -it $CONTAINER_ID composer require 'drupal/farm_organic:^2.1'
docker exec -it $CONTAINER_ID composer require 'drupal/farm_map_custom_layers:^1.2'
#docker exec -it $CONTAINER_ID composer require 'drupal/jsonapi_hypermedia:^1.9'
#docker exec -it $CONTAINER_ID composer require 'drupal/openapi_ui:^1.0@RC'
#docker exec -it $CONTAINER_ID composer require 'drupal/openapi_ui_redoc:^1.0@RC'
docker exec -it $CONTAINER_ID composer require 'drupal/farm_map_google:^1.0'
docker exec -it $CONTAINER_ID composer require 'drupal/farm_crop_plan:^3.0@alpha'
docker exec -it $CONTAINER_ID composer require 'drupal/farmos_wfs'
docker exec -it $CONTAINER_ID composer require 'drupal/allow_iframed_site:^3.0'
#Updatedb and clear cache
docker exec -it $CONTAINER_ID drush updb
docker exec -it $CONTAINER_ID drush cr
To make sure all the modules are installed and that I am running the updb and cr commands.
The commented modules are modules that I have had earlier but uninstalled them after one of them had a simliar error to the asset-link ones but since I don’t need them unlike asset-link I just uninstalled them.
Hmmm, I still can’t reproduce this - even installing/uninstalling combinations of the modules you’ve indicated in your script.
Can you test whether https://farm.jorblad.se/alink/backend/models.json loads?
It loads for fine for me now but the problem is weird because the error don’t always show up either…
Edit: Tested now again since the error did show up but it loads fine now also.
Edit2: I will do some more testing but on my personal computer I haven’t seen this errors but on my work computer I see them… I will try to see if I can understand what it is but it might be EDR or the work proxy that messes something up to throw those errors or if that computer has something in the cache that is a problem.
I think I’ve finally been able to reproduce this…
I’m pretty sure I know what was going on and the error is specific to farmOS 3.2.0. The problem is that the taxonomy term schemas fail to load - i.e. /api/taxonomy_term/unit/resource/schema errors out with TypeError: Symfony\Component\Serializer\Serializer::normalize(): Return value must be of type ArrayObject|array|string|int|float|bool|null, stdClass returned in Symfony\Component\Serializer\Serializer->normalize() (line 159 of /opt/drupal/vendor/symfony/serializer/Serializer.php).
I imagine that between caching and the timing of running drush updb, it might be possible for the errors to appear to persist for a while after the actual update to 3.2.1 occurred. Asset Link caches the result of /alink/backend/models.json - which in this case would have been broken. Also I’ve noticed those warning banners don’t always show up on the page request they’re actually associated with.
All that said, I think the problem should be gone with farmOS 3.2.1 and we can probably consider this resolved - though I may look into the error handling a bit sometime soon.
2 Likes
I also see it less and less often so sounds about right that it’s only caches from 3.2.0
1 Like
