postiz-app icon indicating copy to clipboard operation
postiz-app copied to clipboard

[BUG] Scheduled Posts not working.

Open montecassino opened this issue 1 year ago β€’ 6 comments

πŸ“œ Description

I scheduled multiple posts for all of my registered channels inside the app (IG, FB Page, Threads, Bluesky, and Pinterest) at 11:43 AM. I waited for the app to have it all posted, but it didn't happen.

image

πŸ‘Ÿ Reproduction steps

It seems like the problem stems from multiple posts with the same timestamp. In my case, it's 11:43 AM.

πŸ‘ Expected behavior

Have all items be posted.

πŸ‘Ž Actual Behavior with Screenshots

image

πŸ’» Operating system

MacOS

πŸ€– Node Version

20

πŸ“ƒ Provide any additional context for the Bug.

No response

πŸ‘€ Have you spent some time to check if this bug has been raised before?

  • [X] I checked and didn't find similar issue

Are you willing to submit PR?

None

montecassino avatar Nov 18 '24 03:11 montecassino

Is this the managed version of Postiz or self hosted?

nevo-david avatar Nov 18 '24 03:11 nevo-david

It's self-hosted with Coolify. Yesterday I tried rescheduling my posts to have unique individual timestamps like 11:40, 11:41, 11:42 and etc, but it didn't run, I can't seem to find the logs that it attempted to do so ("proceccsing" console.log)

montecassino avatar Nov 19 '24 02:11 montecassino

UPDATE:

I decided to check all scheduled posts last night to see if they got registered in Redis, and the answer is yes. All of these IDs (bull:post:<ID>) below were supposed to run today at exactly 8:40 AM.

bull:post:cm3ogfcqf000l592ukep6smqo"
"bull:post:cm3og7zgv000f592ur0tyvrdp"
"bull:post:id"
"bull:post:cm3ky3m9q001bd5x1m1gkakfg"
"bull:post:cm3kykekh0027d5x1e5amj1mw"
"bull:post:meta"
"backup1"
"bull:post:cm3ky9kb4001md5x1baeuo4th"
"backup4"
"bull:post:cm3ky3mcg001fd5x1xqa6ayih"
"bull:post:cm3ky9kdd001od5x1eryyb2dv"
"bull:post:cm3ky9kcg001nd5x1kln2q565"
"bull:post:cm3ky3mah001cd5x1xroq7f2a"
"bull:post:cm3kxkxsh000od5x1io1v3pok"
"bull:post:cm3kykelj0029d5x1b7rs4dto"
"bull:post:cm3ky9kec001pd5x1obpzzevq"
"bull:post:cm3og58wq0009592uugzya7n6"
"bull:post:cm3ky3mb2001dd5x13bgfa9kk"
"bull:post:cm3kyfqlg001zd5x1ldhn7on8"
"backup2"
"bull:submit:meta"
"bull:post:events"
"bull:post:cm3ky3mbo001ed5x1vpa9sl6u"
"bull:post:stalled-check"
"backup3"
"bull:submit:stalled-check"
"bull:post:cm3oge6gq000j592u3xgtxhlh"
"bull:post:cm3kyfqk1001xd5x1dbkxsgt5"
"bull:post:delayed"

NOTE: Some of the posts above are scheduled to be "automatically" posted 2 - 3 days from now.

Then I checked my social media channels right now to see if the scheduled posts got posted, but again, it didn't work; not a single post was made. I revisited the Redis instance to see if the keys are still present, they're all gone.

1) "backup2"
2) "bull:submit:meta"
3) "bull:post:stalled-check"
4) "backup3"
5) "bull:submit:stalled-check"
6) "backup1"
7) "bull:post:meta"
8) "backup4"

Also checked the logs to see if "proceccsing" console.log is present, turned out that it's missing.

Checked the DB, and one of the rows shows that the status is still in Queued, which is correct because obviously it hasn't been posted

image

My hypothesis is that the keys that are being stored in Redis by BullMQ have some form of expiration and the expiration precedes the actual processing or posting event.

OR it is being discarded due to an error?

image

montecassino avatar Nov 20 '24 01:11 montecassino

I also encountered a similar issue. After investigation, I found that I had started multiple services, and since all the services were connected to the same Redis, it caused the delayed tasks to seemingly be randomly pushed to one of the services. Due to a VPN issue with one of the services, the scheduled posts assigned to this service failed to send. The symptom was that the scheduled posts would randomly fail, and there were no corresponding logs on the other services.

vinelink avatar Nov 22 '24 06:11 vinelink

Mine's just using a single service but in some cases, I saw the logs from Redis where it states that the Redis instance went from Master to Slave and based on that I did this CONFIG SET "slave-read-only" "no". Checked the scheduled posts that was supposed to be posted today, and viola it's not posted. Will investigate further.

montecassino avatar Nov 25 '24 03:11 montecassino

Found the problem. I got infected by the Kinsing malware. The bots scan open ports, typically targeting containerized Redis or other database ports, and exploit weaknesses in your security, such as missing authentication.

I blindly copied and pasted the Docker Compose file from the docs page (moved too fast, I guess).

I highly recommend that the team make the following changes to the documentation:

  1. Modify the Docker Compose examples to encourage adding a username and password to DB instances like Redis.
  2. Modify the Docker Compose examples to avoid exposing database ports to the internet. For example:
ports:
  - '6379:6379'  # We don't need to expose this to the internet since only the Postiz app will use this port, and it's on the same Docker network (postiz-network).

If anyone else has been infected, I recommend the following steps:

  1. Flush all Redis keys.
  2. Stop the Postiz containers.
  3. Delete the volume for the Redis instance.
  4. Restart the entire stack by re-pulling all images.
  5. There’s no need to clean the whole host or your main machine.

@nevo-david

montecassino avatar Nov 26 '24 14:11 montecassino

Thank you! Closing it for now.

nevo-david avatar Dec 02 '24 12:12 nevo-david