Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/ign-argentina/argenmap/llms.txt

Use this file to discover all available pages before exploring further.

A well-written bug report is one of the most valuable contributions you can make to an open-source project. It saves maintainers hours of guesswork, helps reproduce the problem reliably, and gets a fix shipped faster. Before filing an issue, it is important to confirm that what you are seeing is actually a defect in Argenmap itself — not a configuration error on your end, such as a malformed JSON file, an incorrect WMS URL, or a map service that is temporarily unavailable. This page walks you through everything you need to do before and during the reporting process.
Do not report misconfiguration as a bug. If a WMS or WMTS service is down, returns an error, or is spelled incorrectly in your data.json or preferences.json, that is not an Argenmap defect. Verify your configuration files are valid JSON and that all referenced service URLs are reachable before opening an issue.

​
Pre-Report Checklist

Before you open a new issue, work through each of these steps. They protect everyone’s time and ensure the tracker stays focused on genuine defects.
1

Confirm the problem is in Argenmap, not your configuration

Check that your data.json and preferences.json files are syntactically valid JSON and that every layer URL is correct and accessible. You can paste your JSON into a validator to rule out syntax errors. If removing or replacing the suspect layer makes the problem disappear, the issue is in your configuration — not in Argenmap.
2

Search existing issues for duplicates

Before creating a new report, search the GitHub issue tracker to make sure no one has already reported the same problem. Someone may have already filed an issue — or even received a fix that is pending release.Browse existing issues at github.com/ign-argentina/argenmap/issues.
3

Reproduce in the latest version and the beta

Check whether the bug appears in the latest stable release, the master branch, or both. Also test against the live beta deployment at mapa.ign.gob.ar/beta — this helps determine whether the bug has already been addressed in unreleased code, or whether it is a regression introduced by recent changes.
4

Test in multiple browsers

Open the same scenario in at least two different browsers (for example, Chrome and Firefox). If the bug only appears in one browser, note that clearly — it significantly narrows the scope of investigation and may determine which label the issue receives.

​
What to Include in a Bug Report

The quality of a bug report determines how quickly it can be acted on. The following sections describe each piece of information maintainers need.
Your issue title is the first thing a maintainer reads. Make it specific enough that someone can understand the problem without opening the full report.
❌ Bad title✅ Good title
Problem with linesDrawing a polyline on mobile causes the map to freeze
Layer not workingWMS layer fails to load when URL contains special characters
Bug in panelSide panel does not close on iOS Safari after selecting a layer
A good pattern to follow is: “Doing X in Y causes Z” — action, context, and consequence.
Include the exact browser name and version number, your operating system (including version), and the version of Argenmap where the problem occurs.To find the Argenmap version, check the URL of the deployment you are using, or look at the src/docs/version file in the repository. For example:
Browser:  Firefox 126.0 on Windows 11
OS:       Windows 11 22H2
Argenmap: v2.3.1
Provide a numbered list of exact steps that reliably trigger the bug. Assume the reader is starting from a fresh browser with a default Argenmap installation. The more precise your steps, the faster someone can reproduce and diagnose the problem.Example:
1. Open Argenmap at https://mapa.ign.gob.ar/beta/
2. Click the drawing tool in the toolbar and select "Polyline"
3. Click three points on the map to begin drawing
4. Tap the last point on a mobile device to close the shape
5. Observe: the map freezes and the toolbar becomes unresponsive
Note whether the bug appears in:
  • The stable release only
  • The master branch only
  • Both stable and master
This information tells maintainers whether they are looking at a known regression or a long-standing defect, and helps prioritize the fix.

​
Finding the Responsible Commit with git bisect

If a bug appears in the master branch but the stable release works correctly, it was introduced by a specific commit somewhere between those two points. Git’s built-in bisect command performs a binary search through your commit history to identify exactly which commit caused the regression — often in just a few steps. The general workflow is: 
# Start a bisect session
git bisect start

# Mark the current (broken) state as bad
git bisect bad

# Mark a known-good commit or tag as good
git bisect good v2.3.1

# Git checks out a middle commit — test it, then mark it:
git bisect good   # if the bug is not present
git bisect bad    # if the bug is present

# Repeat until git identifies the first bad commit
# When done, reset your repository to the original state
git bisect reset
Once git bisect identifies the responsible commit, include its hash in your bug report. This makes it dramatically easier for a maintainer to understand what changed and why.

Build docs developers (and LLMs) love

Get started for freeTalk to us