Clarification/missing documentation?

[tttp]

I have the feeling we have more docs already that I couldn't find on docs.proca.app, but I might be wrong and it's missing

rabbitmq queues

https://docs.proca.app/components.html#queue-topology (not necessarily the right place and might be existing already, many be only a missing link)

• explain the different types of queues, what is created automatically/who push/pull on it
• explain the default/fallback to the instance/ftsq if not set up for the org (for MTT or thank you or template)

is there any monitoring already of the queues to check if they are consumed or not?

action updates

I remember 3 cases where the "email status" changes after the initial action:

• double opt-in/action confirmation: if the action is confirmed-> changing the processing status of the action(?)
• double opt-in/optin confirmation: when newsletter subscription is confirmed through a special link on the thank you email-> what is changed here?
• bounce email-> if mailjet informs of a bounce/blocked email-> what does it change here?

bounce email doesn't seem to be working/not clear on the impact: is this supposed to decrease the counter? to send an event? to update a status somewhere?

[marcinkoziej]

explain the different types of queues, what is created automatically/who push/pull on it

This is explained in: https://docs.proca.app/Proca.Pipes.Topology.html

• 3 exchanges reflect 3 stages of processing (supporter confirms their data, moderator confirms the action, action is delivered)
• Each exchange has build in worker queues attached, if workers are enabled. Worker queues are read by Proca workers.
• Each exchange has custom queue attached, if enabled on Org. Custom queues are meant to be read by external client.
• Worker and custom queues have a Dead Letter Exchange attached (DLX), so unprocessed messages are temporarily stored there, so they do not clog the processing. They come back after 30 seconds. [Improvement: change this timeout when the retry queue gets bigger]
• When data is shared with your org by other org, you only receive action onto deliver exchange.
• Routing key is: ${campaign}.${action_type}, eg. no_to_gmo.share
• The action format is v1 or v2, depending on org.action_schema_version. Defaults to 2 for new Orgs.

[marcinkoziej]

explain the default/fallback to the instance/ftsq if not set up for the org (for MTT or thank you or template)

There is no automatic fallback in the server. I believe proca admin sets some defaults on a new org (like SYSTEM email backend).

New org -> no email backend nor anything else, all processing flags are set to false.

[marcinkoziej]

is there any monitoring already of the queues to check if they are consumed or not?

There is way to see them in rabbitmq.proca.app, but there is no alerts for this - you'd have to use the API to fetch queue lengths and alert this way.

[marcinkoziej]

remember 3 cases where the "email status" changes after the initial action:

double opt-in/action confirmation: if the action is confirmed-> changing the processing status of the action(?)
double opt-in/optin confirmation: when newsletter subscription is confirmed through a special link on the thank you email-> what is changed here?
bounce email-> if mailjet informs of a bounce/blocked email-> what does it change here?

bounce email doesn't seem to be working/not clear on the impact: is this supposed to decrease the counter? to send an event? to update a status somewhere?

I've updated the Action data processing guide as well as Proca.Supporter docs to explain this.

the 2 cases are:

• on action DOI (supporter confirmation in Proca naming), there can be doi=1 param that ALSO sets email_status=double_opt_in
• in a thank you email, there can be a link to just do email doi (the signature was already accepted and we just ask for subscription).
• if email bounces, the supporter is rejected, their actions are rejected, and the supporters email_status is also marked as bouncing.