Conversation
✅ Deploy Preview for dither-staging ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
@mazzy89 I have been trying to make subscriptions work locally but no matter what I do I end up with errors when I'm not sure if it's a local issue. The issue is on service subscribe. I can see that previous to that there is communication from the client, in the logs you can see initial replication slot creation query, so communication works. The issue is related to the protocol being used at some point, it seems, but so far I can't find the exact point. Tried with PostgreSQL 14, 17 and 18. Traceback: PostgreSQL log: |
|
If you have tried with the local stack nothing will work and it is expected. you would need to prepare and configure the whole db config for logical replication enabling at the level of the db the WAL set to logical and increase the number of the slots. At the current time tests have been conducted against provider db. |
I have done it: Also: SELECT pg_create_logical_replication_slot('slot1', 'pgoutput');
CREATE PUBLICATION general FOR ALL TABLES;Being |
It seems we can't use a connection pool with LogicalReplicationService because it creates the client, and current implementation doesn't allow to customize how clients are created.
jeronimoalbi
force-pushed
the
feed-sync
branch
from
d3c56b6 to
8bc938a
Compare
This change address specific replication to avoid growing the WAL with data that won't be needed.
This is required to be container friendly
Also removed tests because right now there are no relevant tests.
| export interface Publisher { | ||
| // Publishes a Dither message | ||
| publish: (msg: any) => Promise<void>; | ||
| } |
There was a problem hiding this comment.
| export interface Publisher { | |
| // Publishes a Dither message | |
| publish: (msg: any) => Promise<void>; | |
| } | |
| export interface Publisher<T = unknown> { | |
| // Publishes a Dither message | |
| publish: (msg: T) => Promise<void>; | |
| } |
There was a problem hiding this comment.
use a generic interface for better type-safety, any is still possible, but this encourages defining the message type even if it is polymorphic
| export class ConsolePublisher implements Publisher { | ||
| async publish(msg: any): Promise<void> { | ||
| if (msg) { | ||
| logger.info('Post', { msg }); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
| export class ConsolePublisher implements Publisher { | |
| async publish(msg: any): Promise<void> { | |
| if (msg) { | |
| logger.info('Post', { msg }); | |
| } | |
| } | |
| } | |
| export class ConsolePublisher implements Publisher { | |
| async publish(msg): Promise<void> { | |
| if (msg) { | |
| logger.info('Post', { msg }); | |
| } | |
| } | |
| } |
here msg is inferred as unknown from the Publisher interface
| ]), | ||
| ); | ||
| } | ||
| } |
There was a problem hiding this comment.
for the TelegramPublisher, define the PostMessage type and use it for the generic Publisher
There was a problem hiding this comment.
In 9d5e37d added an interim type for Post.
I think we should have a generic package that defines the Post type which also has support for sending posts to a Telegram channel. Right now the type is defined in the api-main package, which also implements a sendMessage()
cc @salmad3
|
@mazzy89 I think we need the CI workflows for this app, which could be done in a separate PR |
|
Sure. we can merge and then i will wire everything to release. |
github-project-automation
bot
moved this from Ready to Build
to Done
in Dither Community Board
3 participants
This PR adds a new app to publish new posts to a Telegram channel.
It uses PostgreSQL logical replication to read new posts.
Closes #403