Please remove incorrect call to future::plan()

[HenrikBengtsson]

Hello, author of future here. You're using:

QBMS/R/http.R

Lines 1 to 2 in f4b0ce3

	# Set the future plan to enable parallel execution
	future::plan(future::multisession)

Please note that this is not the correct way and place to set the future plan. It will be called during package installation, but it would be applied when the package is loaded (which I think might have been your train of thought).

Please remove that completely.

FYI, also please don't set the future plan globally by other means. If you really want to set it, do so temporarily, as explained in https://future.futureverse.org/articles/future-7-for-package-developers.html#avoid-changing-the-future-backend.

[khaled-alshamaa]

What an honor to receive guidance directly from the author of future R package 😍 Thank you, @HenrikBengtsson!

And what a shame that it has taken me this long to respond. I have been deeply occupied with the development of the next QBMS release and, unfortunately, did not review the open issues for the past couple of months. My sincere apologies for the delayed response.

I had independently noticed the problem with initializing the multisession plan during package loading and first attempted to address it in this commit: 17dd6ac

That change removed the package-level future::plan() call and moved the plan initialization into the function that performs the parallel requests. However, I was manually saving and restoring the previous plan.

After reviewing the package-developer guidance you shared, I have now updated the implementation to apply the plan locally using:

with(future::plan(future::multisession, workers = workers), local = TRUE)

The latest change is available here: f921145

QBMS deliberately uses local multisession processing for these concurrent HTTP requests. The plan is now created only when the function runs and is scoped locally, so the user's previous future plan is automatically restored when the function exits.

I hope this now addresses the issue correctly while preserving the intended QBMS behavior. Please let me know if I have still overlooked anything.

Thank you again for reporting this and for pointing me toward the appropriate implementation.