Refresh token task warning: A separate task was already scheduled under the name

[ajstewart]

ALL software version info

(this library, plus any other relevant software, e.g. bokeh, python, notebook, OS, browser, etc should be added within the dropdown below.)

Software Version Info

bokeh                   3.6.1
panel                   1.5.3

macOS 15.0.1

Description of expected behavior and the observed behavior

It's hard to come up with a reproducible example as it's related to auth, but recently I've started to see this following warning when a user refreshes their session or logs on again

WARNING:param._state00002: A separate task was already scheduled under the name '66652_Joe Bloggs-refresh-access-tokens'. The new task will be ignored. If you want to replace the existing task cancel it with `state.cancel_task('66652_Joe Bloggs-refresh-access-tokens')` before adding adding a new task under the same name.
2024-11-14 11:49:02,311 A separate task was already scheduled under the name '66652_Joe Bloggs-refresh-access-tokens'. The new task will be ignored. If you want to replace the existing task cancel it with `state.cancel_task('66652_Joe Bloggs-refresh-access-tokens')` before adding adding a new task under the same name.

I am using a generic auth type with an Azure B2C setup.

I'm reporting this because as far I can see the task is actually attempted to be canceled before creating the new one:

panel/panel/auth.py

Lines 1133 to 1140 in e24f443

	log.debug("%s scheduling token refresh in %d seconds", type(self).__name__, expiry_seconds)
	task = f'{user}-refresh-access-tokens'
	try:
	state.cancel_task(task)
	except KeyError:
	pass
	finally:
	state.schedule_task(task, refresh_cb, at=expiry_date)

I'm not sure where the number comes from in the task name, it seems to be attached to the user.

I don't think this is harming anything to do with the app, but it seems unexpected given the code above.

I am running the app via the CLI: panel serve src/app.py --autoreload --static-dirs assets=./src/assets --port 5006 --setup src/app_setup.py

Complete, minimal, self-contained example code that reproduces the issue

Stack traceback and/or browser JavaScript console output

Screenshots or screencasts of the bug in action

• I may be interested in making a pull request to address this

[sblowers]

There looks to be a disconnect between the naming for schedule_task and cancel_task in panel/io/state.py

In schedule_task the task name is prepended with the PID

panel/panel/io/state.py

Lines 857 to 870 in 8421976

	threaded: bool
	Whether the callback should be run on a thread (requires
	config.nthreads to be set).
	"""
	name = f"{os.getpid()}_{name}"
	if name in self._scheduled:
	if callback is not self._scheduled[name][1]:
	self.param.warning(
	"A separate task was already scheduled under the "
	f"name {name!r}. The new task will be ignored. If "
	"you want to replace the existing task cancel it "
	f"with `state.cancel_task({name!r})` before adding "
	"adding a new task under the same name."
	)

However in cancel_task it assumes that the name given exactly matches the task to remove. So without the PID, it assumes the task doesn't exist and probably raises a KeyError

panel/panel/io/state.py

Lines 575 to 591 in 8421976

	def cancel_task(self, name: str, wait: bool=False):
	"""
	Cancel a task scheduled using the `state.schedule_task` method by name.
	Arguments
	---------
	name: str
	The name of the scheduled task.
	wait: boolean
	Whether to wait until after the next execution.
	"""
	if name not in self._scheduled:
	raise KeyError(f'No task with the name {name!r} has been scheduled.')
	if wait:
	self._scheduled[name] = (None, self._scheduled[name][1])
	else:
	del self._scheduled[name]

To fix, you would probably need to add the PID to the call in the auth.py to match how the task is created, or update the cancel_task function to always add the PID to the task name being cancelled

[hoxbro]

@sblowers, thank you for the investigation!

This is an oversight. Can you submit a PR with your suggested change in cancel_task?