utils

package
v1.5.0 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Jul 21, 2026 License: GPL-3.0 Imports: 10 Imported by: 0

Documentation

Index

Constants

View Source
const (
	DefaultFileMod           os.FileMode = 0o644
	DefaultExecutableFileMod os.FileMode = 0o755
	DefaultDirMod            os.FileMode = 0o755
)
View Source
const DefaultMqttConnectTimeout time.Duration = 30 * time.Second

DefaultMqttConnectTimeout bounds a single MQTT connect attempt.

This is intentionally decoupled from InitialReconnectInterval. An earlier design capped the connect timeout at the shortest reconnect backoff slot (1.5 * InitialReconnectInterval, i.e. ~1s) so a connect attempt could never outlive the next backoff slot. In practice that cap was far too aggressive: the TCP + TLS + MQTT CONNACK handshake to Azure IoT Hub routinely takes longer than a second on slow, high-latency, or lossy links (satellite, congested VPN, poor cellular, distant regions), so every attempt timed out before it could complete and the device never came online.

The connect timeout and the reconnect backoff schedule serve different purposes and are now sized independently: the backoff (ReconnectTimeout Generator) governs how long to wait *between* attempts, while this value governs how long a single attempt is allowed to run. A slow-but-successful handshake is now allowed to complete rather than being aborted prematurely; the reconnect loop still backs off and retries when an attempt genuinely fails. 30s comfortably accommodates a slow TLS handshake while still bounding a truly stuck attempt. Endpoints that need even more can raise it per-device via the device config (mqtt_connect_timeout_seconds).

View Source
const DefaultMqttKeepAlive time.Duration = 30 * time.Second

DefaultMqttKeepAlive is the interval at which the client sends MQTT PING requests to the broker while otherwise idle. It is configured explicitly rather than relying on paho's implicit default so the liveness behavior of a marginal connection is predictable. Together with DefaultMqttPingTimeout it bounds how quickly a silently-dropped connection is detected: the client declares the connection lost (triggering the reconnect loop) within roughly DefaultMqttKeepAlive + DefaultMqttPingTimeout.

View Source
const DefaultMqttPingTimeout time.Duration = 10 * time.Second

DefaultMqttPingTimeout is how long the client waits for a PINGRESP after sending a PING before considering the connection dead. Set explicitly for the same predictability reason as DefaultMqttKeepAlive.

View Source
const InitialReconnectInterval time.Duration = time.Second

InitialReconnectInterval is the base interval the reconnect backoff seeds from. The first reconnect slot produced by ReconnectTimeoutGenerator is therefore ~2x this value (doubled) with up to ±25% jitter, i.e. it is never shorter than 1.5 * InitialReconnectInterval.

Variables

This section is empty.

Functions

func ConfigureLogger

func ConfigureLogger(prefix string, writer io.Writer, level LoggingLevel) hclog.Logger

func LogRecoveredPanic added in v1.4.3

func LogRecoveredPanic(logger hclog.Logger, recovered any, keyvals ...any) error

LogRecoveredPanic logs an already-recovered panic value at Error level along with a stack trace, and returns an error describing it.

Call it from inside a deferred closure that has itself called recover() when the caller needs to react to the panic (for example, to set a named error return so existing error-handling continues). When logging alone is enough, prefer Recover. The keyvals are attached to the log entry to identify the goroutine/context where the panic occurred (e.g. "worker", id).

func NewRequest added in v0.14.0

func NewRequest(method string, url string, body io.Reader) (*http.Request, error)

func NewRequestWithContext added in v0.14.0

func NewRequestWithContext(
	ctx context.Context,
	method string,
	url string,
	body io.Reader,
) (*http.Request, error)

func Recover added in v1.4.3

func Recover(logger hclog.Logger, keyvals ...any)

Recover is a deferred panic handler: it recovers any in-flight panic in the current goroutine and logs it at Error level with a stack trace. It is a no-op when no panic is in flight, so deferring it unconditionally is safe and it never changes normal (non-panic) control flow.

It must be invoked directly via defer (defer utils.Recover(logger, ...)) so the recover() runs in the panicking goroutine's deferred call.

func SafeGo added in v1.4.3

func SafeGo(logger hclog.Logger, fn func(), keyvals ...any)

SafeGo runs fn in a new goroutine guarded by Recover, so a panic in fn is recovered and logged instead of crashing the process. keyvals are attached to the log entry emitted if fn panics.

Types

type FileSystem added in v1.0.0

type FileSystem interface {
	Executable() (string, error)
	ReadFile(name string) ([]byte, error)
	WriteFile(name string, data []byte, perm os.FileMode) error
	MkdirAll(path string) error
	RemoveAll(path string) error
}

func NewFileSystem added in v1.0.0

func NewFileSystem() FileSystem

type LoggingLevel added in v0.9.0

type LoggingLevel string
const (
	Trace   LoggingLevel = "trace"
	Debug   LoggingLevel = "debug"
	Info    LoggingLevel = "info"
	Warn    LoggingLevel = "warn"
	Error   LoggingLevel = "error"
	Off     LoggingLevel = "off"
	Default LoggingLevel = ""
)

type ReconnectTimeoutGenerator

type ReconnectTimeoutGenerator struct {
	// contains filtered or unexported fields
}

func (*ReconnectTimeoutGenerator) Clear

func (g *ReconnectTimeoutGenerator) Clear()

func (*ReconnectTimeoutGenerator) Next

func (g *ReconnectTimeoutGenerator) Next()

func (*ReconnectTimeoutGenerator) Timeout added in v0.2.0

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL