App not synchronizing with server

@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

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

@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:

• A link to this thread: https://1password.community/discussion/comment/627240#Comment_627240
• Your forum username: nikolamilekic

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

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::<:APP::BACKEND::INVOCATION> for op_app::app::App>::invoke
4: core::future::from_generator::GenFuture%3CT as core::future::future::Future>::poll
5: tokio::runtime::task::core::CoreStage::poll
6: tokio::runtime::task::harness::Harness::poll
7: std::thread::local::LocalKey::with
8: tokio::task::local::LocalSet::tick
9: tokio::macros::scoped_tls::ScopedKey::set
10: std::thread::local::LocalKey::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...

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.