* chore: prettier formatting applied
* chore: added some lint fixed
* fix: few lint errors
* chore: prisma and pubsub are now global module
* chore: add encapsulation consistency in service files
* chore: made a cast function private
* chore: cast function made private
* refactor: module imports
* refactor: posthog spelling
fix: handle missing Content-Type when importing curl POST
When importing a curl POST request with a body and no explicit
Content-Type, default to `application/x-www-form-urlencoded`
to match curl's behavior.
Reference: https://everything.curl.dev/http/post/content-type.html
This PR adds a file-based logging system with size-based rotation to the desktop application. It essentially redirects existing diagnostic to size-based rotating files for troubleshooting environment-specific issues.
Closes HFE-801
The desktop application currently lacks a persistent logging mechanism in production environments. Logs are only available through the development mode console.
This PR will help diagnose issues reported in #4859, #4950, #5003, discussions #4984 and #4986.
Mainly aiming to understand errors in specific environments that can't be reproduced in our testing setups.
This implementation uses the tracing ecosystem (`tracing`, `tracing_subscriber`, `tracing_appender`) along with `file_rotate` to create log files in the platform's log directory. The logs are automatically rotated when they reach `10MB`, with a maximum of `5` files retained.
Thinking 10 * 5 MB is reasonable disk usage while maintaining sufficient history.
The system currently writes to both the console (with ANSI colors where supported) and to files (without ANSI formatting for readability). Log levels are currently controlled via the `RUST_LOG` environment variable, defaulting to "debug" when not specified.
| OS | Log File Path |
|---------|------------------------------------------------------|
| Windows | `C:\Users\<username>\AppData\Local\io.hoppscotch.desktop\logs\io.hoppscotch.desktop.log` |
| macOS | `~/Library/Logs/io.hoppscotch.desktop/io.hoppscotch.desktop.log` |
| Linux | `~/.local/share/io.hoppscotch.desktop/logs/io.hoppscotch.desktop.log` |
This fix replace `sys-info v0.9.1` with
the more actively maintained `sysinfo 0.34.2`
which does return size of the disk in bytes.
Closes#5017, HFE-831
Rebased on #5010, consider merging that first.
Issues:
Appload fails to load with a "Storage full" error despite
having sufficient disk space.
This was caused by a unit mismatch in the `sys-info` crate
which returns disk space in kilobytes instead of bytes.
- sys_info::disk_info() returns values in KB, see:
60ecf1470a/c/linux.c (L119)
- The `StorageFull` error was triggered when comparing
raw bytes against a KB value, causing false positive
Changes:
- Rewrite the `ensure_space` function to find the correct disk of the config dir
- Add a new `StorageError::DiskNotFound` for cases where the disk cannot
be resolved
fix: add win version checks for DWM attr api
This adds version checking before using Windows 11-specific DWM APIs.
Closes HFE-821
The desktop app crashes on startup on older Windows versions (pre-Windows 11)
due to unsupported DWM API calls for dark mode and caption styling.
According to docs at https://learn.microsoft.com/en-us/windows/win32/api/dwmapi/ne-dwmapi-dwmwindowattribute,
both `DWMWA_USE_IMMERSIVE_DARK_MODE` and `DWMWA_CAPTION_COLOR` attributes
are only supported starting with Windows 11 Build 22000.
> DWMWA_USE_IMMERSIVE_DARK_MODE: [...] This value is supported starting
> with Windows 11 Build 22000"
and
> DWMWA_CAPTION_COLOR: [...] This value is supported starting
> with Windows 11 Build 22000.
See https://github.com/hoppscotch/hoppscotch/discussions/4984 for more details,
for reports of app crashing immediately on startup with these errors:
```
Failed to set dark mode: Error { code: HRESULT(0x80070057), message: "The parameter is incorrect." }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[0417/150158.530:ERROR:window_impl.cc(122)] Failed to unregister class Chrome_WidgetWin_0. Error = 1412
```
The tests were all over the place, both attributes (sometimes!) seems to be present
on Windows 10 1809 and even earlier, only if it was installed with network access,
so perhaps this is due to Windows updates? Other times, they weren't, especially on VMs.
The issue is reproducible on Windows Server 2019 Datacenter (v10.0.17763),
which is equivalent to Windows 10 version 1809.
This version is too old to support DWMWA_USE_IMMERSIVE_DARK_MODE,
which is only **officially supported** starting with Windows 11 Build 22000
according to Microsoft's documentation.
So at the moment, relying on official docs seems to be the right call,
and themes are definitely something app shouldn't crash for regardless.
* feat(infra): desktop aio build workflow
This PR adds an actions workflow pipeline for building and
packaging the self-hosted Hoppscotch Desktop app across different platforms.
Platform supported right now are
- Windows x86_64 (`msi`)
- MacOS x64 and ARM64 (`dmg`)
- Linux x86_64 (`.deb`, `AppImage`)
The workflow can be triggered either automatically when a new release is created
or manually through workflow dispatch.
Manual trigger has a few customizations like
- build version,
- to support building a different version of the app from prior releases
- repository to checkout,
- to support building from a different source
- branch or tag to build from,
- to support building a different release
- release notes,
- these are mainly for the updater manifest
- custom environment file content, and
- to customize instance target
- an option to disable code signing
- this is self explanatory
- this doesn't disable updater signing
Closes HFE-800
For Linux builds, the workflow generates packages using Ubuntu 24.04,
yet it still contains some specific libraries
```
libwebkit2gtk-4.1-0=2.44.0-2 \
libwebkit2gtk-4.1-dev=2.44.0-2 \
libjavascriptcoregtk-4.1-0=2.44.0-2 \
libjavascriptcoregtk-4.1-dev=2.44.0-2 \
gir1.2-javascriptcoregtk-4.1=2.44.0-2 \
gir1.2-webkit2-4.1=2.44.0-2;
```
For more information, see https://github.com/hoppscotch/hoppscotch/issues/4880
```
Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...
```
Also see:
tauri-apps/tauri#8588https://bugs.webkit.org/show_bug.cgi?id=180739https://bugs.webkit.org/show_bug.cgi?id=165246tauri-apps/tauri#8535
Also `code-signing-cli` is often installed directly from source bin,
since installing it from `crates.io` sometimes breaks the CI:
```
error[E0599]: no method named `fetch_mode_no_cors` found for struct `reqwest::RequestBuilder` in the current scope
--> C:\Users\runneradmin\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\reqwest-middleware-0.4.1\src\client.rs:532:31
|
532 | inner: self.inner.fetch_mode_no_cors(),
| ^^^^^^^^^^^^^^^^^^ method not found in `RequestBuilder`
```
The build dependency management is a bit complex but it should handles
all necessary system dependencies and builds for the web app first
before bundling it into the desktop app using `webapp-bundler`.
On Windows, the workflow uses Microsoft Azure code signing integration (when
enabled).
For macOS, the workflow builds separate packages for both Intel (x64) and Apple
Silicon (ARM64). It similar to Windows workflow, implements Apple's code signing
and notarization (when credentials are provided).
The final step generates an update manifest that includes info about
all built packages, their signatures, and download URLs.
This manifest is used by the app's auto-updater.
* fix(infra): temporarily disable release workflow
* fix(infra): use repo secret for env var contents
These changes add explicit `Content-Type` headers to direct (via `native` interceptor)
authentication requests after changes made in [PR #4931](https://github.com/hoppscotch/hoppscotch/pull/4931) that modified how `Content-Type`
headers are handled in the `relay` plugin.
In [issue #4905](https://github.com/hoppscotch/hoppscotch/issues/4905), that was about Hoppscotch Agent and Native interceptor inconsistently
handling `Content-Type` headers. The issue had two main manifestations,
duplicate headers - when overriding the `Content-Type` header in the UI or using OAuth2 authentication, the agent
would send multiple `Content-Type` headers to the web server. This caused undefined behavior
and often 400 errors for backends that don't accept duplicate headers.
And inconsistent overrides - even when the content type was explicitly set (for example to
`application/json;v=2`), the agent/native would inconsistently apply this override. Server
logs revealed that roughly 50% of requests would use the correct override value, while the
others would revert to the default `application/json`.
The two-part solution implemented first in [PR #4911](https://github.com/hoppscotch/hoppscotch/pull/4911) addressed the duplicate headers issue
by implementing header normalization before final relay. This prevented duplicate headers
with different casing from being sent and [PR #4931](https://github.com/hoppscotch/hoppscotch/pull/4931) then resolved the inconsistent override
behavior by removing the automatic `Content-Type` header insertion in the `ContentHandler`
component. As explained in the PR description, this was a temporary workaround until we
implement a HTTP/2-compliant solution with proper normalization.
While the fixes in PR #4911 and #4931 correctly resolved the header inconsistency issues
for general API requests, they introduced a new problem: **requests that previously relied
on the automatic `Content-Type` insertion now have no `Content-Type` header at all**.
This mainly affects direct calls around authentication flows in the desktop module, which
were using the `content.json()` functionality without explicitly setting `Content-Type`
headers, relying on the automatic insertion that has now been removed.
These changes add the now-required explicit `Content-Type` headers to three
authentication-related API calls in the desktop platform module:
- **The initial user details GraphQL query**:
```javascript
headers: {
Authorization: `Bearer ${accessToken}`,
"Content-Type": "application/json",
},
```
- **The magic link email submission endpoint**:
```javascript
headers: {
"Content-Type": "application/json",
},
```
- **The token verification endpoint**:
```javascript
headers: {
"Content-Type": "application/json",
},
```
This will make sure that authentication flows continue to work properly with the native
interceptor after the header handling changes.
As noted in [PR #4931](https://github.com/hoppscotch/hoppscotch/pull/4931), this is considered a **temporary solution**. The plan is to revisit the
content-type handling when we implement a more comprehensive HTTP/2-compliant header
normalization system in the kernel layer.
While HTTP/1.1 headers are case-insensitive
per [RFC 7230](https://tools.ietf.org/html/rfc7230), inconsistent handling across server implementations can treat differently-cased
variations as distinct headers. HTTP/2 ([RFC 7540](https://tools.ietf.org/html/rfc7540)) mandates converting all header field
names to lowercase, which would prevent these issues altogether. In such cases, relying
fully on `MediaType` interface from the kernel will help handling these edge-cases.
