New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
posts://
Encoding Error in notifications
#2309
Comments
Let me look into this when I get home this week. Imo all encodings should be |
So I looked further into this and I think the issue may be on @Emporea's end. The @Emporea perhaps you can explain a bit more on the plugin you're using? The advice of the error is pretty good too. Probably just adding |
I haven't installed any plugins. I am using the default docker image. So what exactly do you mean by saying |
Strange, the error implies you're environment has a Edit: There is definitely something that is customized because even your error message says it's trying to initialize a |
@dgtlmoon maybe can add to this. It looks like under the hood he perhaps created some custom hooks. The hooks appear to be re-encoding the |
@caronc you are correct :) thanks again for your input, yes thats our little custom extension |
Greetings, can confirm this error happened on my 'vanilla' deployment, I am using post to a Gotify notification service which failed in one instance which contained a non-latin character:
|
hello, can confirm this exist when chinese char in the body, and using Bark with |
If you are using JSON for your Some examples here - this one does not do any encoding and you get the error (It will also have issues if your diff has a " double quote):
But with this one, everything is encoded and you do not get the error:
|
posts://
Encoding Error in notifications
I was tracking a website that made a change using a smiley ('ツ'). I saw that changedetection recognized the change, but it didnt produce a notification via posts://.
Logs said this:
Is there something I can do or does this need to be done in the code of the NotifyPlugin?
Also i am wondering about the two different date formats, I dont know why the plugin uses a different one.
The text was updated successfully, but these errors were encountered: