Describe the bug
Nearspark crashes when it encounters an unsupported image format. This disrupts the thumbnail loading and prevents the rest of the thumbnails in the batch from loading. It can also result in the Kubernetes pod going into a CrashLoopBackOff state that will persist (preventing any thumbnails from loading) until Nearspark is restarted, e.g. with kubectl scale deploy nearspark --replicas=0 -n hcce and then kubectl scale deploy nearspark --replicas=1 -n hcce.
To Reproduce
Steps to reproduce the behavior:
- run
kubectl logs -l app=nearspark -f -n hcce in a terminal to view and follow the logs of the Nearspark pod.
- Open a Spoke project.
- Go to Assets > Icosa Gallery, then enter
Vertex-first 120-cell into the search field.
- See that the image for the asset never loads and an error is printed in the Nearspark logs (which have also stopped following).
- Wait for a bit and then use
kubectl get pods -n hcce to see that the pod is in the CrashLoopBackOff state (you may need to run the command a few times to see it).
- Clear the search and then run
kubectl scale deploy nearspark --replicas=0 -n hcce followed by kubectl scale deploy nearspark --replicas=1 -n hcce to fix your Nearspark pod.
Expected behavior
Nearspark should log the error (preferably with the type of image that isn't supported) and continue on without crashing (probably returning the stock error image). This should minimize the disruption and allow you to see exactly which asset(s) caused the issue.
Desktop (please complete the following information):
- OS: GNU/Linux
- Browser: Firefox
- Version: 144
Additional context
A partial workaround is to quickly switch to a different category so that the Kubernetes pod doesn't go into the CrashLoopBackOff state. Note: this only works if you realize there is a problem soon after it begins and it doesn't allow you to browse the category (if you go back it will crash again).
Additional Note: the example asset is currently present in the first batch of assets in the Science category/tag of Icosa Gallery, which basically prevents the category/tag being browsed with thumbnails.
Full error:
node:internal/process/promises:289
triggerUncaughtException(err, true /* fromPromise */);
^
[Error: Input buffer contains unsupported image format]
Describe the bug
Nearspark crashes when it encounters an unsupported image format. This disrupts the thumbnail loading and prevents the rest of the thumbnails in the batch from loading. It can also result in the Kubernetes pod going into a
CrashLoopBackOffstate that will persist (preventing any thumbnails from loading) until Nearspark is restarted, e.g. withkubectl scale deploy nearspark --replicas=0 -n hcceand thenkubectl scale deploy nearspark --replicas=1 -n hcce.To Reproduce
Steps to reproduce the behavior:
kubectl logs -l app=nearspark -f -n hccein a terminal to view and follow the logs of the Nearspark pod.Vertex-first 120-cellinto the search field.kubectl get pods -n hcceto see that the pod is in theCrashLoopBackOffstate (you may need to run the command a few times to see it).kubectl scale deploy nearspark --replicas=0 -n hccefollowed bykubectl scale deploy nearspark --replicas=1 -n hcceto fix your Nearspark pod.Expected behavior
Nearspark should log the error (preferably with the type of image that isn't supported) and continue on without crashing (probably returning the stock error image). This should minimize the disruption and allow you to see exactly which asset(s) caused the issue.
Desktop (please complete the following information):
Additional context
A partial workaround is to quickly switch to a different category so that the Kubernetes pod doesn't go into the
CrashLoopBackOffstate. Note: this only works if you realize there is a problem soon after it begins and it doesn't allow you to browse the category (if you go back it will crash again).Additional Note: the example asset is currently present in the first batch of assets in the
Sciencecategory/tag of Icosa Gallery, which basically prevents the category/tag being browsed with thumbnails.Full error: