Blocking Firewall Apply (filter reload functionality)

[VIKMSTR]

Is your feature request related to existing pfSense functionality that is missing from the API? Please describe.
Not really, just a feature improvement

Is your feature request related to a problem? Please describe.
When creating big amount (tens, hundreds) of firewall rules in a cycle, when apply is set to true (and the rule is immediately applied and filter reloaded), the reloading time gets bigger and bigger (as more and more rules are being added) and sometimes it happens, that the change is not applied.

That's because, the async method filter_configure is called - the request does not wait (block) till the reload finishes in background.

Describe the solution you'd like
I would like have an option to patiently wait for the reloading to finish, so the request gets blocked for some time. There already is a function filter_configure_sync that could be use.

Can we add an option to FirewallApply and FirewallRule request for that?

Describe alternatives you've considered
An alternative is to batch process all of the rules and then call the FirewallApply. However there might be another calls on my client side that does not know if the FirewallApply was finished or not (because it also uses async filter_configure function).

Additional context
I'm ready to help with a PR regarding this issue. Just do not know which approach to choose - (parametrization of existing endpoints?)

[jaredhendrickson13]

I'll have to look into this a little further to see what options are available currently. However, I am trying to move away from the API calling potentially time consuming synchronous functions directly. Mostly because this causes API calls to crash when the web server/nginx timeout is reached. The more REST-like way to do this would be to continue to use the asynchronous function so the API will respond immediately, but implement a way to poll the status of the reload similar to the /api/v1/services/unbound/apply and /api/v1/interface/apply endpoints. This way your scripts can continually check the status of the reload and only proceed when it is safe to do so. An example workflow of this would be:

1. Create firewall rules using POST to /api/v1/firewall/rule
2. Start the filter reload asynchronously using POST to /api/v1/firewall/apply
3. Continually poll the status of the reload using GET to /api/v1/firewall/apply until the applied field in the GET response is true instead of false. (this component doesn't exist currently)
4. Continue with remainder of script.

As a potential work around that should work right now. You could opt to not start the filter reload using the /api/v1/firewall/* endpoints and instead use the /api/v1/diagnostics/command_prompt to call /etc/rc.filter_configure_sync instead.

I'm definitely open to a PR if you have ideas or are up to taking on the task! I'll update this issue if I find any better options.

Thanks!

[jaredhendrickson13]

Looking into this, there is not a clean way to implement the polling option for applying firewall changes yet. Looks like it will be possible once this commit makes its way to a pfSense release. For now, I've added the async field to /api/v1/firewall/apply in the v1.5.0 branch to choose whether filter_configure() or filter_configure_sync() is called.