Misunderstandings associated with the architecture of Buio

Overview

Reference this document when you encounter unexpected or incorrect flag evaluations and suspect network connectivity issues. Follow the chronological steps below to identify the specific problem and its location. If you need assistance at any point, reach out to Technical Support.

Solution

Part 1: Identify

  1. If you answer NO to any of the following, it is likely that the issue is not related to Buio's products or services, but rather to your internal networking architecture.
    • Have you previously used Buio in this area of your application before the error(s) occurred? If YES, proceed to step 2. If NO, review Part 2: Investigate with the engineering teams managing your infrastructure. Inform these teams about your use of Buio in your application or server.
    • Does the network request reach the Relay or Buio streaming/polling endpoints from the SDK? You can enable debug logging to have the relay print a log if it receives the request. If YES, proceed to step 3. If NO, something in the architecture is likely blocking the request. Proceed to Part 2: Investigate.
    • Did the destination encounter an error? To locate the error, check the logging for the Relay or SDK. Verify network connectivity using appropriate cURL commands (or their Windows equivalent) and check if the same error appears in your logs. If YES, reach out to Technical Support for further assistance. If NO, something in the architecture is likely severing the request. Proceed to Part 2: Investigate.

Part 2: Investigate

  • Does the issue align with common misconceptions about Buio architecture? Review the documentation on common misconceptions about Buio architecture.
  • Do you encounter SSL errors or mentions of a certificate issued in the error logs? Check with the application management team to confirm if you use a managed trust store or certificate authority. You may need to update the certificates to recognize Buio.
  • Does all network traffic from your corporate/organizational servers go through a web proxy or web server that proxies requests? Confirm if this web proxy or server allows a long-lived connection between the SDK and Relay/Buio. This is where your architecture may block or drop connections between the SDK and Relay/Buio.
  • Confirm that the web proxy or server does not terminate connections before the heartbeat interval. Some web proxies, by default, may not allow long-lived connections and silently sever them.
  • Do you have different firewalls or web proxies based on the app environment (e.g., one firewall for development and another for production)? Compare the configurations of a working environment with those of non-working environments to identify any differences. Inconsistent occurrences indicate that the problem is due to different firewalls with varying configurations.
  • Do you have a load balancer between the SDK and the Relay Proxy connections? Confirm if connectivity is lost when there is a change to the Relay Proxy instance. If the Relay array is downscaled and the load balancer is not rebalanced, traffic may be routed to a non-existing node, causing the SDK to lose connectivity.
  • Is the issue specific to an end-user? Confirm whether the end user had/still has stable network connectivity when the Buio errors occurred. If they had limited network availability or no network connection, Buio has no control over the end user's network.
  • If the end user uses the application within a secure, locked-down environment, check if they have a firewall that blocks connections to Buio client-side streaming endpoints. Similar to points 2, 3, & 4 above, the end user's architecture may drop or block the connection.

Resources

  • Contributor's guide - High-level guide on how the SDKs communicate with the Buio service.
  • Domain list - All the various endpoints that the SDKs may utilize.
  • Public IP list - An API to access the specific IPs that Buio may use.