~perler the "fix" outlined in this thread is really just a band-aid/workaround (inserting dummy rows so the application starts, then adding 'real' rows and deleting the dummy rows), the issue needs to be fixed by updating the application to not require these dummy rows in the first place.

~rursache ~ctron I agree that things would be much easier on github/gitlab, but I wouldn't get any hopes up. Even though Vincent the developer does have a github account, in his most recent patreon post he mentioned that he just bought an annual subscription to this website/git management system and that he's a big fan of the sourcehut company.

+1 for moving to GitHub, or at least GitLab.

~rursache I don't see any obvious problems unless you haven't restarted the container after updating the rows in the tables.

Unless you copied the post ids from ~ctron's SQL, based on your screenshot it does look like bird makeup is pulling the correct information from twitter as the post id is the most recent for the NPR account (1646138106595139584). NPR actually just quit twitter so I don't expect we'll see them post any new tweets in the near term.

It probably is worth forwarding both http and https ports.

One other note: You shouldn't need to specify specific account and the entire domain in the Moderation:FollowersWhiteListing parameter, the domain alone should cover you.

Hey ~ctron, I'm not using compose but raw docker run. I run PostgreSQL with multiple databases on a different port and manage them with pgAdmin. That's why I want to manually set the port to the PostgreSQL. However, that's the least of my worries right now, as I can't get the bird.makeup instance working even with a brand new PostgreSQL instance on the default port. It's stuck on error 500 with the same errors as the OP.

Important to mention that the original birdslive instance works (clean DB, different name), but I don't have a Twitter API key so I can't use that.

Can you share a valid DB export of your instance or an "almost-vanilla" one? I just want to get this working because using the official bird.makeup site is bugged for me. If I follow any account, it's stuck on "waiting for approval." I'm running my own Mastodon instance and I didn't block any other instance, bots or added any filter.

I used this on a bird.makeup instance, but I did create the database instance a few weeks back. Maybe something has changed in the meantime.

Assuming you use docker-compose, you don't need to change the port of the database. However, you need to change the variable Db:Host to db (which is the name of the database service in the compose file). And remove the port mapping on the db service. This also rejects connections to the database from outside the host. You can then connect to the database using:

docker exec -ti birdsite_db_1 psql -U birdsitelive

It would really be helpful if this got fixed. Here is my SQL snippet which worked around the issue:

DO $$
DECLARE
    id INTEGER;
    mastodon_account TEXT;
    mastodon_domain TEXT;
    mastodon_host TEXT;
BEGIN
    id := nextval('twitter_users_id_seq');
    mastodon_account := 'you';
    mastodon_domain := 'your.instance';
    -- depending on your setup, this may be the domain itself or a specific host
    mastodon_host := 'mastodon.your.instance';

    INSERT INTO twitter_users (
        id, acct, lasttweetpostedid, lasttweetsynchronizedforallfollowersid, lastsync, fetchingerrorcount, twitteruserid
    ) VALUES (
        id,
        'npr', -- twitter account (npr in this case)
        1646138106595139584, -- id/timestamp
        1646138106595139584, -- id/timestamp
        CURRENT_TIMESTAMP, -- timestamp
        0, -- error count
        5392522 -- twitter user id of 'npr'
    );
    
    INSERT INTO followers (
        followings, followingssyncstatus, acct, host, inboxroute, sharedinboxroute, actorid, postingerrorcount
    ) VALUES (
        ARRAY[id],
        JSON_BUILD_OBJECT(id::text, 1646138106595139584),
        mastodon_account,
        mastodon_domain,
        '/users/' || mastodon_account || '/inbox',
        '/inbox',
        'https://' || mastodon_host || '/users/' || mastodon_account,
        0
    );

    -- comment out to actually store
    ROLLBACK;
    
END
$$;

Of course you need to put in your mastodon account, and drop the ROLLBACK once you want to commit.

I also had to restart the container in order for the process to pick up the change, this feels like a transaction issue somewhere.

And don't forget to delete those rows afterwards, as your mastodon instance doesn't have an idea about this subscription.

So the steps for me had been:

• Configure and run the script
• Restart the container
• Create an actual subscription from Mastodon (ensure that it made it into the database)
• Remove manually inserted records