Cloudron deploying wrong/old code? is it possible?

[dgtlmoon]

@girish our version from pip does not show the bug that the user has reported at https://github.com/dgtlmoon/changedetection.io/issues/3591

changedetection.io                       0.50.38

*******************************
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
X-Application: changedetection.io
Subject: ChangeDetection Notificatie - https://changedetection.io/time.php
From: "changedetection.io" <me@localhost>
To: me@localhost
Message-ID: <176218308420.466622.10852343540499566928@localhost>
Date: Mon, 03 Nov 2025 16:18:04 +0100

https://changedetection.io/time.php heeft een wijziging:
---
(changed) 1762182602.7904
(into) 1762183083.0323
---

the notification email is perfect, no weird placeholders

it's still possible we have the bug on our side and something is missing from the issue report, but this part is heavily automated tests (1000+ lines checking this)

[dgtlmoon]

CD_VERSION=0.50.38; curl -sL https://github.com/dgtlmoon/changedetection.io/archive/refs/tags/${CD_VERSION}.tar.gz | tar --strip-components 1 -xvzf -

changedetection.io-0.50.38/docs/package.json
changedetection.io-0.50.38/docs/proxy-example.jpg
changedetection.io-0.50.38/docs/restock-overview.png
changedetection.io-0.50.38/docs/restock-settings.png
changedetection.io-0.50.38/docs/scheduler.png
changedetection.io-0.50.38/docs/screenshot-diff.png
changedetection.io-0.50.38/docs/screenshot-notifications.png
changedetection.io-0.50.38/docs/screenshot.png
changedetection.io-0.50.38/docs/visualselector-anim.gif
changedetection.io-0.50.38/docs/web-page-change-conditions.png
changedetection.io-0.50.38/requirements.txt
changedetection.io-0.50.38/runtime.txt
changedetection.io-0.50.38/setup.py
...

then

$ ./changedetection.py -d /tmp
2025-11-03 16:23:38.541 | DEBUG    | changedetectionio.content_fetchers:<module>:62 - Falling back to selenium as fetcher
2025-11-03 16:23:38.625 | DEBUG    | changedetectionio.queue_handlers:__init__:53 - RecheckPriorityQueue initialized successfully
2025-11-03 16:23:38.625 | DEBUG    | changedetectionio.queue_handlers:__init__:358 - NotificationQueue initialized successfully
2025-11-03 16:23:38.626 | INFO     | changedetectionio.flask_app:<module>:90 - System locale default is ('en_AU', 'UTF-8')
2025-11-03 16:23:38.626 | SUCCESS  | changedetectionio:main:131 - changedetection.io version 0.50.38 starting.
...

then I send a test SMTP notification by following https://changedetection.io/time.php (plaintext document)

*******************************
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
X-Application: changedetection.io
Subject: ChangeDetection Notificatie - https://changedetection.io/time.php
From: "changedetection.io" <me@localhost>
To: me@localhost
Message-ID: <176218348959.467872.404048423206685716@localhost>
Date: Mon, 03 Nov 2025 16:24:49 +0100

https://changedetection.io/time.php heeft een wijziging:
---
(changed) 1762183083.0323
(into) 1762183488.7614
---

*******************************

everything works perfect

[imc67]

In the Cloudron app the output in the email is:

https://changedetection.io/time.php heeft een wijziging: --- @changed_PLACEMARKER_OPEN1762182459.6731@changed_PLACEMARKER_CLOSED @changed_into_PLACEMARKER_OPEN1762182761.7355@changed_into_PLACEMARKER_CLOSED ---

[dgtlmoon]

@imc67 I would need to SSH into that machine.... is it possible?

[imc67]

@dgtlmoon said in Cloudron deploying wrong/old code? is it possible?:

@imc67 I would need to SSH into that machine.... is it possible?

I think its better that @girish is trying to reproduce on a Cloudron server (or you can use the Cloudron demo yourself)

[dgtlmoon]

@girish is it possible that when the cloudron image updates, the old container is running still or something? @imc67 I'm almost 100% certain a fresh install would work....

[girish]

@imc67 Did I understand correctly that I should send a test email and this will reproduce the bug?

Works for me.. but still playing around. It seems the new default format is HTML Color but in your github issue it is HTML. That doesn't seem to matter though.

[imc67]

@girish said in Cloudron deploying wrong/old code? is it possible?:

@imc67 Did I understand correctly that I should send a test email and this will reproduce the bug?

Works for me.. but still playing around. It seems the new default format is HTML Color but in your github issue it is HTML. That doesn't seem to matter though.

steps to reproduce:

1. create a watcher on https://changedetection.io/time.php
2. set it to Chrome and settings like this:
   
3. set it to check for every 5 minutes
4. notification method: email via mailtos://user:pw@domain.xx?smtp=mail.domain.xx&user=x@x.xx

[imc67]

@dgtlmoon said in Cloudron deploying wrong/old code? is it possible?:

I'm almost 100% certain a fresh install would work....

If I make a backup in Changedetection, delete the app, reinstall fresh and restore the backup will everything also general settings en mailtos: work again?

[girish]

@imc67 that works for me as well.

I think it's probably related to some migration logic from older version. I am trying a Change Detection from 2-3 weeks ago and see if it's reproducible .

[imc67]

@girish said in Cloudron deploying wrong/old code? is it possible?:

trying a Change Detection from 2-3 weeks ago

mine was from January 2023

[imc67]

well this doesn't work!! There is a way to make a backup and download a zipfile but, I uninstalled, fresh install and wanted to import the backup zip ... there is no functionality for that or I completely missed it

So I imported on the new app a app-backup, after that the issue is still there

[girish]

@imc67 said in Cloudron deploying wrong/old code? is it possible?:

well this doesn't work!! There is a way to make a backup and download a zipfile but, I uninstalled, fresh install and wanted to import the backup zip ... there is no functionality for that or I completely missed it

You have to manually upload to the server's file system and import it from there. you didn't miss this, it's not implemented (well, so far, we haven't planned to implement it).

[imc67]

Beside the old app (imported with issue) I created a fully new one and checked: this one works!!!

So there must be something during almost 3 years of updating that went wrong

[imc67]

@girish I meant the backup inside ChangeDetection, there you can create a backup and export it as zip. But inside ChangeDetection I don't see a function to import that zip ... or I overlooked in the hurry

[imc67]

Ok, I "solved" it by creating a new app on a new domain, manually match all settings and watches, tested (WORKED!) and then did a Cloudron backup and imported that backup on the app at the original domain (of the "faulty" app).

Result: I have a freshly new app with previous settings on the original app-domain.

Case closed for me ... but the issue is not really solved for all those that didn't do this.

[dgtlmoon]

https://github.com/dgtlmoon/changedetection.io/issues/3576 this is kinda similar but the user reports it as solved

[dgtlmoon]

let me verify an old tag install then upgrade...

[dgtlmoon]

Tried old 0.45.9, - Plaintext test

• Set up "mailto://me@localhost" on test SMTP server as "Global notification setting", and "Text" notification type
• Watch: Added the time.php test with "system default" notification format

shut down, switch to 0.50.38, start up, updates ran,
SMTP test was OK no placeholders

@imc67 can you email me your url-watches.json again? then i can compare what settings are different maybe