Support Topics Documentation Slack YouTube Blog

beforeDeleteFileOrDirectory and afterDeleteFileOrDirectory File Event Handlers not being fired


I’m trying to implement some codeless backend functionality that executes when a file is removed from the system using the
afterDeleteFileOrDirectory and beforeDeleteFileOrDirectory Event Handlers, however i’m unable to get these to fire in any scenario I try.

  • I’ve implemented a simple codeless handler that prints to the real-time console.
    Screenshot 2021-02-13 at 16.18.42

  • I then remove a file from the root files directory in the hope of seeing the output message in the RT console.

Neither handler seems to be called (as I see no console output). I’ve also tried:

  • Using a different model (as opposed to the default)
  • Deleting from different directories
  • Switching them between blocking and non-blocking.
  • I also have a custom codeless endpoint that removes files, and this also isn’t triggering either of the callbacks.

I’m using the eu-develop server and there were issues with RT at some point today (which was resolved), however logger output is appearing from other handlers I have set up, so it doesn’t seem like a logger issue to me.

Is there something i’m missing with these?

Many thanks,

Backendless Version (v6.2.4)

Application ID


Hello @Grant_Kerr

  1. Event handlers do not work if the action is performed manually. The event handler only works using the API.
  2. The event handler does not fire if the request comes from business logic (to avoid looping)
  3. The message will be logged, but it will not get into real-time immediately, because the log message will be in the buffer according to the default settings of Log Policy.

The log buffer policy controls the following aspects of log message submission from the client app to the server:

  • the maximum number of log messages stored in the buffer
  • the maximum time interval (in seconds) between message transmissions

The log exhibits the behavior defined below based on the configuration parameters established with the API:

  • flushes the log messages to the server when the maximum of messages have been collected
  • flushes the messages after the configured time interval elapses
  • delivers log messages immediately if the number of messages is set to 0 (zero)

Regard, Viktor

Ah, I didn’t realise those handlers worked that way. Thanks very much for clearing that up.