Activate a scheduled functions only when ceremony is running

[baumstern]

Following functions are invoked constantly when it has been deployed to Firebase, even if there is no registered ceremony:

• every 1 minutes
  • checkAndRemoveBlockingContributor
• every 30 minutes
  • startCeremony
  • stopCeremony

[0xjei]

Could we have scripts that allow us to remove these features when they are not useful? (always coordinator side)

[0xjei]

UP: Related to the comment on #192, do you have any proposal/idea for an alternative/optimized approach? What is the real world cost of having the se functions up and running constantly?

[baumstern]

UP: Related to the comment on #192, do you have any proposal/idea for an alternative/optimized approach? What is the real world cost of having the se functions up and running constantly?

45K invocations per month which packs dashboard with meaningless metrics and costs 0.3 EUR per month. IMHO, it is similar to keeping the light on in a room when it is not in use. I believe it is best to turn off lights when they are not in use.

[0xjei]

Thanks for clarifying this with the graph. I definitely agree with your thoughts.

• We could make a step forward by getting rid of startCeremony and stopCeremony by using the alternative approach proposed here #192.
• For the checkAndRemoveBlockingContributor function, we only need this function when or more ceremonies are open.

Therefore, we could limit the consumption and usage by having two scripts that needs to be manually triggered by the coordinator:

• After setup, around ceremony opening, deploying the function
• After ceremony closing, before finalization, removing the function

This could be intended as best practice to avoid unnecessary cost and should be stated in the coordinator guide. What do you think about this guidelines and approach? @gurrpi

[baumstern]

Thanks for clarifying this with the graph. I definitely agree with your thoughts.

• We could make a step forward by getting rid of startCeremony and stopCeremony by using the alternative approach proposed here Ceremony start time could delayed up to ~30 minutes #192.
• For the checkAndRemoveBlockingContributor function, we only need this function when or more ceremonies are open.

Therefore, we could limit the consumption and usage by having two scripts that needs to be manually triggered by the coordinator:

• After setup, around ceremony opening, deploying the function
• After ceremony closing, before finalization, removing the function

This could be intended as best practice to avoid unnecessary cost and should be stated in the coordinator guide. What do you think about this guidelines and approach? @gurrpi

How about get rid of scheduled run behavior and trigger checkAndRemoveBlockingContributor function when only it is needed? For example, when user is trying to do contribute action? I think your idea is sound from a technical standpoint, but I think providing people with guide documents and expecting them to follow them involves an element of uncertainty, as it relies on individuals to accurately follow the procedures outlined in the document.

[0xjei]

Thanks for clarifying this with the graph. I definitely agree with your thoughts.

• We could make a step forward by getting rid of startCeremony and stopCeremony by using the alternative approach proposed here Ceremony start time could delayed up to ~30 minutes #192.
• For the checkAndRemoveBlockingContributor function, we only need this function when or more ceremonies are open.

Therefore, we could limit the consumption and usage by having two scripts that needs to be manually triggered by the coordinator:

• After setup, around ceremony opening, deploying the function
• After ceremony closing, before finalization, removing the function

This could be intended as best practice to avoid unnecessary cost and should be stated in the coordinator guide. What do you think about this guidelines and approach? @gurrpi

How about get rid of scheduled run behavior and trigger checkAndRemoveBlockingContributor function when only it is needed? For example, when user is trying to do contribute action?

Hmm, I think this part is pretty much different from the other two scheduled functions. A contributor can block the waiting queue (e.g., unexpected crash, misbehavior) at any time within the time frame for his/her contribution. Consequently, moving this check based on a user action would result in just one arbitrary check for blocking contributors (not enough). Furthermore, the users' main task regarding the waiting queue mechanism is to request queuing and not to unclog the queue itself, that check should occur at system level. Therefore, a scheduled function would have been optimal in this case. IMO, an alternative solution will be hard to find and complex to implement. I think the trade-off of manually getting rid of the function, could still be the best option rn.

I think your idea is sound from a technical standpoint, but I think providing people with guide documents and expecting them to follow them involves an element of uncertainty, as it relies on individuals to accurately follow the procedures outlined in the document.

Agree!

@ctrlc03 @gurrpi Thoughts on this conversation?