run prettier to reformat markdown

Signed-off-by: Sean Chittenden <sean.chittenden@crowdstrike.com>

Author: sean-

CHANGELOG.md

@@ -42,6 +42,7 @@ OpenSearch Go Client builds using [Go](https://go.dev/doc/install) 1.24 at a min
 To build the project on Windows, use [WSL2](https://learn.microsoft.com/en-us/windows/wsl/install), the compatibility layer for running Linux applications.
 
 Install `make`
+
 ```
 sudo apt install make
 ```
@@ -67,15 +68,15 @@ In order to test opensearch-go client, you need a running OpenSearch cluster. Yo
 
 ### Composing an OpenSearch Docker Container
 
-Ensure that Docker is installed on your local machine. You can check by running `docker --version`. Next, navigate to your local opensearch-go repository. Run the following command to build and start the OpenSearch docker container. 
+Ensure that Docker is installed on your local machine. You can check by running `docker --version`. Next, navigate to your local opensearch-go repository. Run the following command to build and start the OpenSearch docker container.
 
 ```
 make cluster.build cluster.start
 ```
 
 This command will start the OpenSearch container using the `docker-compose.yaml` configuration file. During the build process, the necessary dependencies and files will be downloaded, which may take some time depending on your internet connection and system resources.
 
-Once the container is built and running, you can open a web browser and navigate to localhost:9200 to access the OpenSearch docker container. 
+Once the container is built and running, you can open a web browser and navigate to localhost:9200 to access the OpenSearch docker container.
 
 In order to differentiate unit tests from integration tests, Go has a built-in mechanism for allowing you to logically separate your tests with [build tags](https://pkg.go.dev/cmd/go#hdr-Build_constraints). The build tag needs to be placed as close to the top of the file as possible, and must have a blank line beneath it. Hence, create all integration tests with build tag 'integration'.
 
@@ -143,5 +144,4 @@ After you have opened your project, you need to specify the location of the Go S
 
 ### Vim
 
-To improve your vim experience with Go, you might want to check out [fatih/vim-go](https://github.com/fatih/vim-go).
-For example it correctly formats the file and validates it on save.
+To improve your vim experience with Go, you might want to check out [fatih/vim-go](https://github.com/fatih/vim-go). For example it correctly formats the file and validates it on save.

DEVELOPER_GUIDE.md

@@ -41,21 +41,23 @@ The release process is standard across repositories in this org and is run by a
 6. Create a tag, e.g. `v4.3.0`, and push it to the GitHub repo. This [makes the new version available](https://go.dev/doc/modules/publishing) on [pkg.go.dev](https://pkg.go.dev/github.com/opensearch-project/opensearch-go/v4).
 7. Draft and publish a [new GitHub release](https://github.com/opensearch-project/opensearch-go/releases/new) from the newly created tag.
 8. Create a new `Unreleased` section in the [CHANGELOG](CHANGELOG.md), increment version in [version.go](internal/version/version.go) to the next developer iteration (e.g. `4.3.1`), and make a pull request with this change into `main`, e.g. [opensearch-go#448](https://github.com/opensearch-project/opensearch-go/pull/448).
-    ```
-    ## [Unreleased]
 
-    ### Added
+   ```
+   ## [Unreleased]
 
-    ### Changed
+   ### Added
 
-    ### Deprecated
+   ### Changed
 
-    ### Removed
+   ### Deprecated
 
-    ### Fixed
+   ### Removed
 
-    ### Security
+   ### Fixed
+
+   ### Security
+
+   ### Dependencies
+   ```
 
-    ### Dependencies
-    ```
 9. Run `go list` with the new version to refresh [pkg.go.dev](https://pkg.go.dev/github.com/opensearch-project/opensearch-go/v4), e.g. `go list -m github.com/opensearch-project/opensearch-go/v4@v4.3.0`.

RELEASING.md

@@ -12,28 +12,31 @@
 # Upgrading Opensearch GO Client
 
 ## Upgrading to >= 5.0.0
+
 Version 5.0.0 returns `*opensearch.StringError` error type instead of `*fmt.wrapError` when response received from the server is an unknown JSON. For example, consider delete document API which returns an unknown JSON body when document is not found.
 
 Before 5.0.0:
+
 ```go
 docDelResp, err = client.Document.Delete(ctx, opensearchapi.DocumentDeleteReq{Index: "movies", DocumentID: "3"})
 if err != nil {
 	fmt.Println(err)
-	
+
 	if !errors.Is(err, opensearch.ErrJSONUnmarshalBody) && docDelResp != nil {
 		resp := docDelResp.Inspect().Response
 		// get http status
 		fmt.Println(resp.StatusCode)
 		body := strings.TrimPrefix(err.Error(), "opensearch error response could not be parsed as error: ")
 		errResp := opensearchapi.DocumentDeleteResp{}
-		json.Unmarshal([]byte(body), &errResp) 
-		// extract result field from the body 
+		json.Unmarshal([]byte(body), &errResp)
+		// extract result field from the body
 		fmt.Println(errResp.Result)
 	}
 }
 ```
 
 After 5.0.0:
+
 ```go
 docDelResp, err = client.Document.Delete(ctx, opensearchapi.DocumentDeleteReq{Index: "movies", DocumentID: "3"})
 if err != nil {
@@ -50,20 +53,19 @@ if err != nil {
 }
 ```
 
-
 ## Upgrading to >= 4.0.0
 
 Version 4.0.0 moved the error types, added with 3.0.0, from opensearchapi to opensearch, renamed them and added new error types.
 
 ### Error Types
 
-Before 4.0.0:
-Error types:
+Before 4.0.0: Error types:
+
 - `opensearchapi.Error`
 - `opensearchapi.StringError`
 
-With 4.0.0:
-Error types
+With 4.0.0: Error types
+
 - `opensearch.Error`
 - `opensearch.StringError`
 - `opensearch.ReasonError`
@@ -75,9 +77,11 @@ Error types
 Version 3.0.0 is a major refactor of the client.
 
 ### Client Creation
+
 You now create the client from the opensearchapi and not from the opensearch lib. This was done to make the different APIs independent from each other. Plugin APIs like Security will get there own folder and therefore its own sub-lib.
 
 Before 3.0.0:
+
 ```go
 // default client
 client, err := opensearch.NewDefaultClient()
@@ -150,7 +154,6 @@ createIndexResponse, err := client.Indices.Create(
 )
 ```
 
-
 ### Responses
 
 With the version 3.0.0 the lib no longer returns the opensearch.Response which is just a wrap up http.Response. Instead it will check the response for errors and try to parse the body into existing structs. Please note that some responses are so complex that we parse them as [json.RawMessage](https://pkg.go.dev/encoding/json#RawMessage) so you can parse them to your expected struct. If you need the opensearch.Response, then you can call .Inspect().

UPGRADING.md

@@ -1,9 +1,9 @@
 - [User Guide](#user-guide)
-	- [Example](#example)
-	- [Amazon OpenSearch Service](#amazon-opensearch-service)
-		- [AWS SDK v1](#aws-sdk-v1)
-		- [AWS SDK v2](#aws-sdk-v2)
-	- [Guides by Topic](#guides-by-topic)
+  - [Example](#example)
+  - [Amazon OpenSearch Service](#amazon-opensearch-service)
+    - [AWS SDK v1](#aws-sdk-v1)
+    - [AWS SDK v2](#aws-sdk-v2)
+  - [Guides by Topic](#guides-by-topic)
 
 # User Guide
 
@@ -268,7 +268,7 @@ func example() error {
 	}
 
 	ctx := context.Background()
-    
+
     ping, err := client.Ping(ctx, nil)
     if err != nil {
         return err

USER_GUIDE.md

@@ -323,6 +323,7 @@ You can choose different routing strategies based on your cluster setup:
 ```
 
 The smart selector automatically detects different operation types:
+
 - **Bulk operations** (`/_bulk`) -> Routes to ingest nodes
 - **Ingest pipeline operations** (`/_ingest/`) -> Routes to ingest nodes
 - **Search operations** (`/_search`) -> Routes to data nodes

guides/bulk.md

@@ -75,11 +75,13 @@ client, err := opensearch.NewClient(opensearch.Config{
 ```
 
 When `IncludeDedicatedClusterManagers` is disabled (default), these nodes will be EXCLUDED from request routing:
+
 - Nodes with only "cluster_manager" role
 - Nodes with only "master" role (deprecated)
 - Nodes with "cluster_manager" + "remote_cluster_client" roles only
 
 These nodes will be INCLUDED (even with IncludeDedicatedClusterManagers disabled):
+
 - Cluster manager + data nodes
 - Cluster manager + ingest nodes
 - Cluster manager + warm nodes (OpenSearch 3.0+ for searchable snapshots)
@@ -293,4 +295,4 @@ func main() {
     // 4. Refresh node list periodically
     // 5. Log deprecation warnings for old role names
 }
-```
+```

guides/node_discovery_and_roles.md

@@ -16,23 +16,27 @@ This feature is **opt-in** and complements OpenSearch's node discovery to provid
 ## Benefits
 
 ### Performance Optimization
+
 - **Bulk operations** execute faster on nodes with ingest processors and pipelines
 - **Search operations** execute faster on nodes with data and search capabilities
 - **Reduced resource contention** by avoiding inappropriate node usage
 
 ### High Availability
+
 - **Graceful degradation** when specialized nodes are unavailable
 - **No operation failures** due to missing node types
 - **Automatic failover** to any healthy node
 
 ### Operational Simplicity
+
 - **Zero configuration** required for basic optimization
 - **Transparent fallback** behavior requires no application changes
 - **Compatible with existing** round-robin and custom selectors
 
 ## Quick Start
 
 ### Default Behavior: Round-Robin (No Request Routing)
+
 ```go
 // Basic round-robin across all nodes
 client, err := opensearch.NewClient(opensearch.Config{
@@ -42,6 +46,7 @@ client, err := opensearch.NewClient(opensearch.Config{
 ```
 
 ### Enable Request Routing (Recommended)
+
 ```go
 import "github.com/opensearch-project/opensearch-go/v4/opensearchtransport"
 
@@ -57,6 +62,7 @@ client, err := opensearch.NewClient(opensearch.Config{
 The client will now automatically route requests based on operation type and node roles.
 
 ### Manual Configuration (Advanced)
+
 ```go
 // Manual chain configuration for custom routing
 client, err := opensearch.NewClient(opensearch.Config{
@@ -94,16 +100,28 @@ smartSelector := opensearchtransport.NewSmartSelector()
 
 The smart selector automatically detects operation types from HTTP request patterns:
 
-| Operation Type           | HTTP Patterns                               | Target Nodes         |
-|--------------------------|---------------------------------------------|----------------------|
-| **Bulk operations**      | `POST /_bulk`, `PUT /_bulk`                 | Ingest-capable nodes |
-|                          | `POST /{index}/_bulk`, `PUT /{index}/_bulk` |                      |
-| **Ingest pipelines**     | `GET/PUT/DELETE /_ingest/pipeline/{id}`     | Ingest-capable nodes |
-|                          | `POST /_ingest/pipeline/_simulate`          |                      |
-| **Search operations**    | `GET/POST /_search`, `GET/POST /_msearch`   | Data nodes           |
-|                          | `GET/POST /{index}/_search`                 |                      |
-| **Document retrieval**   | `GET/HEAD /{index}/_doc/{id}`               | Data nodes           |
-| **All other operations** | Everything else                             | Round-robin fallback |
+**Bulk operations** → Ingest-capable nodes
+
+- `POST /_bulk`, `PUT /_bulk`
+- `POST /{index}/_bulk`, `PUT /{index}/_bulk`
+
+**Ingest pipelines** → Ingest-capable nodes
+
+- `GET/PUT/DELETE /_ingest/pipeline/{id}`
+- `POST /_ingest/pipeline/_simulate`
+
+**Search operations** → Data nodes
+
+- `GET/POST /_search`, `GET/POST /_msearch`
+- `GET/POST /{index}/_search`
+
+**Document retrieval** → Data nodes
+
+- `GET/HEAD /{index}/_doc/{id}`
+
+**All other operations** → Round-robin fallback
+
+- Everything else
 
 ### Chain-of-Responsibility Pattern (Advanced)
 
@@ -176,6 +194,7 @@ nodes:
 ```
 
 **Routing behavior:**
+
 - **Bulk operations** -> `ingest-1` or `ingest-2`
 - **Search operations** -> `data-1` or `data-2`
 - **Other operations** -> Round-robin across `ingest-1`, `ingest-2`, `data-1`, `data-2`
@@ -191,6 +210,7 @@ nodes:
 ```
 
 **Routing behavior:**
+
 - **All operations** -> `opensearch-single` (no routing needed)
 - **No performance difference** vs basic round-robin
 - **Same code works** in development and production
@@ -209,6 +229,7 @@ nodes:
 ```
 
 **Routing behavior:**
+
 - **Bulk operations** -> Fallback to round-robin across all data nodes
 - **Search operations** -> `data-1`, `data-2`, or `data-3` (preferred)
 - **Still beneficial**: Search operations get data-node preference
@@ -372,15 +393,19 @@ client, err := opensearch.NewClient(opensearch.Config{
 ### Common Scenarios
 
 **Q: My bulk operations seem slow despite using SmartSelector**
+
 - **A**: Check that your cluster has nodes with `ingest` role. If not, operations will fall back to data nodes, which is still correct behavior.
 
 **Q: I get "no connections found" errors**
+
 - **A**: This indicates a different issue (network, authentication, discovery, lack of healthy hosts). Request routing uses existing connections and does not cause connection failures.
 
 **Q: How do I verify routing is working?**
+
 - **A**: Use debug logging and monitor which nodes receive requests. In mixed clusters, you should see operations favoring appropriate node types based on your selector chain.
 
 **Q: Can I disable request routing?**
+
 - **A**: Yes, simply don't provide a Selector or use `opensearchtransport.NewRoundRobinSelector()` directly.
 
 ## Migration Guide
@@ -423,6 +448,7 @@ client, err := opensearch.NewClient(opensearch.Config{
 ### Development vs Production
 
 **Development (single node):**
+
 ```go
 // Simple setup - smart routing provides no benefit but no harm
 client, err := opensearch.NewClient(opensearch.Config{
@@ -432,6 +458,7 @@ client, err := opensearch.NewClient(opensearch.Config{
 ```
 
 **Production (mixed cluster):**
+
 ```go
 // Full optimization with discovery and smart routing
 client, err := opensearch.NewClient(opensearch.Config{

guides/request_routing.md

@@ -353,6 +353,7 @@ The smart selector automatically detects operation types and routes them to the
 ### Routing Strategy Overview
 
 The smart selector provides automatic routing based on the operation being performed:
+
 - **Search operations** (`/_search`, `/_msearch`, document retrieval) -> Data nodes
 - **Bulk operations** (`/_bulk`) -> Ingest nodes
 - **Ingest operations** (`/_ingest/`) -> Ingest nodes