App not synchronizing with server

nikolamilekic
nikolamilekic
Community Member
in Desktop betas (Mac, Windows, and Linux)

I'm using 1Password on my Mac (beta channel), iPhone (production channel), and PC (beta channel), and several times now I've had to restart the app to force the app to sync with the server to get changes from other devices. Before reporting any bugs I was wondering if I could get a better understanding of how this is supposed to work. Specifically:

  • Is the client pulling changes from the server (and if so how often), or is the server pushing changes to the client?
  • If the client is pulling, is there a way to force it to? I seem to remember seeing this option (maybe in an older version) but can't find it anymore. I could be mistaking it for something else tho.
  • Was this logic changed in the beta channel and would it be helpful to revert to the production channel before writing any bug reports (not preferable but I'm willing to do it)? Keeping in mind I use mixed channels (see above), are your expectations the same regardless of app channel (beta/production)?

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided

Comments

  • Joshua_ag
    Joshua_ag

    Hey @nikolamilekic,

    Thanks so much for trying out 1Password's betas! We really appreciate it!

    On to your questions:

    Is the client pulling changes from the server (and if so how often), or is the server pushing changes to the client?

    The app sets up a connection with 1Password.com to listen for any changes. When a change is made, a notification is sent to that connection, 1Password then syncs it immediately.

    If the client is pulling, is there a way to force it to? I seem to remember seeing this option (maybe in an older version) but can't find it anymore. I could be mistaking it for something else tho.

    1Password will always set up a new connection and try to do a full sync when unlocking the app. So if you want a guaranteed way to trigger a sync lock and then unlock the app.

    Was this logic changed in the beta channel and would it be helpful to revert to the production channel before writing any bug reports (not preferable but I'm willing to do it)? Keeping in mind I use mixed channels (see above), are your expectations the same regardless of app channel (beta/production)?

    The logic has not been changed. The changes we have been working on is how that connection (the one I mentioned while answering your first question) handles different / limited networking environments like the ones you may see in an enterprise work environment.

    What sounds like what is happening is that there is an app or something on your network that is closing that connection, thus causing the app to be unaware of the changes since the app thinks the device is offline. You could try restarting your devices into safe mode (for Mac) and safe mode with Networking (for Windows) to see if there is an app on your devices that is causing 1Password to lose the connection.

  • nikolamilekic
    nikolamilekic
    Community Member
    edited January 2022

    Hi @Joshua_ag,

    Thanks for the input. I'm not on an enterprise network, nor do I have any extraordinary security software that could be blocking those connections. Are you sure that's the only possible cause? I tested it again this morning and managed to reproduce it twice on my Mac. Both times the notebook was closed and in sleep mode for around half an hour. In both cases, I found the following in the log file. Is this related?

    ERROR 2022-01-26T10:03:04.855 tokio-runtime-worker(ThreadId(1)) [1P:op-app/src/app/backend.rs:200] AppError at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/convert/mod.rs:540:9
ModelError(ItemWithIdNotFound(ItemId(250473846)))

Stack backtrace:
   0: backtrace::backtrace::trace
   1: anyhow::backtrace::capture::Backtrace::capture
   2: op_app::app::backend::immediate
   3: op_app::app::backend::<impl op_runtime::Backend<op_app::app::backend::Invocation> for op_app::app::App>::invoke
   4: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   5: tokio::runtime::task::core::CoreStage<T>::poll
   6: tokio::runtime::task::harness::Harness<T,S>::poll
   7: std::thread::local::LocalKey<T>::with
   8: tokio::task::local::LocalSet::tick
   9: tokio::macros::scoped_tls::ScopedKey<T>::set
  10: std::thread::local::LocalKey<T>::with
  11: tokio::park::thread::CachedParkThread::block_on
  12: tokio::runtime::handle::Handle::block_on
  13: std::sys_common::backtrace::__rust_begin_short_backtrace
  14: core::ops::function::FnOnce::call_once{{vtable.shim}}
  15: std::sys::unix::thread::Thread::new::thread_start
  16: __pthread_start

    I also have a couple of instances of these two events in the log file

    WARN  2022-01-26T10:03:48.531 tokio-runtime-worker(ThreadId(3)) [1P:op-data-layer/src/sync.rs:502] The B5 Notifier for (XBCKOWHVYFCUVGTLOJ3DJ6IUUM) has disconnected.
INFO  2022-01-26T10:03:49.004 tokio-runtime-worker(ThreadId(1)) [1P:op-data-layer/src/sync.rs:511] The B5 Notifier for (XBCKOWHVYFCUVGTLOJ3DJ6IUUM) has connected, now monitoring for events.

    I can send you the full log file if you need it, I can't attach it here tho...

  • Joshua_ag
    Joshua_ag

    @nikolamilekic,

    Thanks so much for the follow up and logs. There could be other reasons why the app may disconnect if something isn't working right.

    The full report would be very helpful.

    Attach the diagnostics to an email message addressed to support+forum@1password.com.

    With your email please include:

    You should receive an automated reply from our BitBot assistant with a Support ID number. Please post that number here. Thanks very much!

  • nikolamilekic
    nikolamilekic
    Community Member

    @Joshua_ag here's the ID number: [#AUG-65446-552]

  • Joshua_ag
    Joshua_ag

    @nikolamilekic,

    Thanks for doing that! I have located your email in our internal system and I'll respond to you from there.

    ref: AUG-65446-552

This discussion has been closed.