How to deal with file deletion?

[jupyter-server]

How to deal with file deletion?

[dlqqq]

@dleen I think the simplest way would be to allow users to configure what events a FIM listens to. That way, you can disable the FIM from listening to delete events from the CM, call get_id(<path>) and delete the associated commenting data, and then call FIM.delete() yourself (since all event listeners are public methods anyways).

This would be a pretty simple change to implement, do you want to give it a try? We use traitlets.config to implement configurability of our classes. You would want to define a new trait that accepts a list that defines the CM event actions the class will listen to, say self.cm_actions. This trait should default to listening to all the actions, e.g. default to the value ["get", "save", "rename", "copy", "delete"]. Then, you would want to change the logic of the below method to bind the action to None if the action isn't listed in self.cm_actions.

def get_handlers_by_action(self) -> Dict[str, Optional[Callable[[Dict[str, Any]], Any]]]:
    return {
        "get": None,
        "save": lambda data: self.save(data["path"]),
        "rename": lambda data: self.move(data["source_path"], data["path"]),
        "copy": lambda data: self.copy(data["source_path"], data["path"]),
        "delete": lambda data: self.delete(data["path"]),
    }

[kevin-bates]

Specifically tuning FIM's event listener works fine if your application is the only server extension in town. However, if other server extensions expect, in this case, "delete" events, they'll be screwed.

Seems like @dleen's suggestion of FIM emitting events (index, move, delete, copy?) and letting each server extension determine which events are pertinent is a good way to go. This eliminates the ambiguity of which listener acts first on the same event and doesn't interfere with multiple server extension configurations.

[dlqqq]

@kevin-bates I'm not quite sure I follow. Dependent extensions need to be able to query for the file ID before the FIM deletes the record, not before. Emitting an event in the FIM methods to allow extensions to respond after deletion doesn't seem to solve @dleen 's issue.

[dleen]

The deletion event would include the ID of the file deleted which would probably work

[kevin-bates]

Correct. All you (@dleen) need is the ID. This way the ambiguity is resolved. All events emitted by the FIM would include the corresponding ID(s).

[dlqqq]

Ah, thank you both for clarifying. Then yes, we could implement support for this.

(btw I'm insanely busy with Jupyter AI, so I'd love to accept open source contributions for any of the issues opened recently, just reach out to me so I can assign you 🤗)

[dleen]

Yes I'm willing to work on these issues - just wanted to discuss before jumping into the code