Updates ioredis to ^5.0.4

[janthurau]

No description provided.

[janthurau]

Unfortunately Redlock is not really compatible yet, mike-marcacci/node-redlock#160

[kylealwyn]

Might be worth a fork? node-redlock might be a ghost town

[janthurau]

I'm thinking of just dropping locking there. Any opinions?

Scenarios that I have in my head:

• When storing to a database, the locking would be moved to database responsibility, which shouldn't be an issue
• When sending an HTTP / another message, each Hocuspocus instance could send the same message at the same time, but that might already happen due to timing issues, as the lock only prevents the hook from running at the exact same time.

If someone really needs to avoid this, they could just put the last store time in the ydoc and check that before doing anything expensive.

[jamespantalones]

@janthurau what are the downsides of removing the locks? if each instance sends the same message at the same time, could that cause clientside issues?

we are also looking into forking and dropping locks as we are running on a cluster, which seems to throw errors when a lock attempts to be acquired twice

https://github.com/mike-marcacci/node-redlock#using-clustersentinel

[lzj723]

Hi @jamespantalones , you can try below if you just want to solve require lock errors.
It's efficient for me though the code is not that succinct:

try {
  // try to get a lock
  const lock = await redlock.acquire(['xxx'], 2000);
  try {
    // do something with lock
  } catch (e) {
    console.error(`log something`, e);
  } finally {
    // Release the lock. And it may throw an ERROR too.
    try {
      await lock.release();
    } catch (e) {
      // console.error('lock release failed:', e);
    }
  }
} catch (e) {
  // It will throw an ERROR when require lock failed, so we need to catch it.
  console.warn('require lock failed:', e);
}

[janthurau]

I have released v2.1.0-alpha.0 which adds compatibility to ^5.0.4 and removes redlock. Please let me know if that breaks something