Merge branch 'microsoft:main' into main

Author: glorious-beard

.github/_typos.toml

@@ -42,6 +42,7 @@ prompty = "prompty"       # prompty is a format name.
 ist = "ist"               # German language
 dall = "dall"             # OpenAI model name
 pn = "pn"                 # Kiota parameter
+nin = "nin"               # MongoDB "not in" operator
 
 [default.extend-identifiers]
 ags = "ags" # Azure Graph Service

.github/workflows/codeql-analysis.yml

@@ -6,7 +6,8 @@ name: "CodeQL"
 
 on:
   push:
-    branches: ["main", "experimental*", "feature*", "*-development"]
+    # TODO: Add "feature*" back in again, once we determine the cause of the ongoing CodeQL failures.
+    branches: ["main", "experimental*", "*-development"]
   schedule:
     - cron: "17 11 * * 2"
 

.github/workflows/dotnet-build-and-test.yml

@@ -104,9 +104,9 @@ jobs:
         shell: bash
         if: github.event_name != 'pull_request' && matrix.integration-tests
         run: |
-          export INTEGRATION_TEST_PROJECTS=$(find ./dotnet -type f -name "*IntegrationTests.csproj" | grep -v "Experimental.Orchestration.Flow.IntegrationTests.csproj" | tr '\n' ' ')
+          export INTEGRATION_TEST_PROJECTS=$(find ./dotnet -type f -name "*IntegrationTests.csproj" | grep -v "Experimental.Orchestration.Flow.IntegrationTests.csproj" | grep -v "VectorDataIntegrationTests.csproj" | tr '\n' ' ')
           for project in $INTEGRATION_TEST_PROJECTS; do
-            dotnet test -c ${{ matrix.configuration }} $project --no-build -v Normal --logger trx
+            dotnet test -f net8.0 -c ${{ matrix.configuration }} $project --no-build -v Normal --logger trx
           done
         env:
           # Azure OpenAI Deployments

docs/decisions/0032-agents.md

@@ -376,7 +376,7 @@ await WriteMessagesAsync(chat.InvokeAsync(agent1));
 await WriteMessagesAsync(chat.InvokeAsync(agent2));
 
 // The entire history may be accessed.
-// Agent specific history is an adapataton of the primary history.
+// Agent specific history is an adaptaton of the primary history.
 await WriteMessagesAsync(chat.GetHistoryAsync());
 await WriteMessagesAsync(chat.GetHistoryAsync(agent1));
 await WriteMessagesAsync(chat.GetHistoryAsync(agent2));
@@ -401,7 +401,7 @@ await write_message(chat.invoke(agent1))
 await write_message(chat.invoke(agent2))
 
 # The entire history may be accessed.  
-# Agent specific history is an adapataton of the primary history.
+# Agent specific history is an adaptaton of the primary history.
 await write_message(chat.get_history())
 await write_message(chat.get_history(agent1))
 await write_message(chat.get_history(agent2))
@@ -470,4 +470,4 @@ chat.add_agent(agent3)
 
 # Execute the chat until termination
 await write_message(chat.invoke())
-```
+```

docs/decisions/0042-samples-restructure.md

@@ -70,7 +70,7 @@ samples/
 Pros:
 
 - Simpler and Less verbose structure (Worse is Better: Less is more approach)
-- Beginers will be presented (sibling folders) to other tutorials that may fit better on their need and use case.
+- Beginners will be presented (sibling folders) to other tutorials that may fit better on their need and use case.
 - Getting started will not be imposed.
 
 Cons:
@@ -101,7 +101,7 @@ Pros:
 
 Cons:
 
-- If the Getting starded example does not have a valid example for the customer it has go back on other folders for more content.
+- If the Getting started example does not have a valid example for the customer it has go back on other folders for more content.
 
 ### Option 3 - Conservative + Use Cases Based Root Categorization
 
@@ -130,7 +130,7 @@ Cons:
 - More verbose structure adds extra friction to find the samples.
 - `KernelContent` or `Modalities` is a internal term that may not be clear for the customer
 - `Documentation` may be confused a documents only folder, which actually contains code samples used in documentation. (not clear message)
-- `Use Cases` may suggest an idea of real world use cases implemented, where in reality those are simple demostrations of a SK feature.
+- `Use Cases` may suggest an idea of real world use cases implemented, where in reality those are simple demonstrations of a SK feature.
 
 ## KernelSyntaxExamples Decomposition Options
 
@@ -449,7 +449,7 @@ Cons:
 
 ### KernelSyntaxExamples Decomposition Option 2 - Concept by Components Flattened Version
 
-Similar approach to Option 1, but with a flattened structure using a single level of folders to avoid deep nesting and complexity authough keeping easy to navigate around the componentized concepts.
+Similar approach to Option 1, but with a flattened structure using a single level of folders to avoid deep nesting and complexity although keeping easy to navigate around the componentized concepts.
 
 Large (Less files per folder):
 

docs/decisions/0046-java-repository-separation.md

@@ -27,7 +27,7 @@ Also managing repository policies that are preferred by all languages is a chall
 complex build process to account for building multiple languages. If a user makes accidental changes to the repository outside their own language,
 or make changes to the common files, require sign off from other languages, leading to delays as we
 require review from users in other languages. Similarly common files such as GitHub Actions workflows, `.gitignore`, VS Code settings, `README.md`, `.editorconfig` etc, become
-more complex as they have to simutaniously support multiple languages.
+more complex as they have to simultaneously support multiple languages.
 
 In a community point of view, having a separate repo will foster community engagement, allowing developers to contribute, share ideas, and collaborate on the Java projects only.
 Additionally, it enables transparent tracking of contributions, making it easy to identify top contributors and acknowledge their efforts. 

docs/decisions/0047-azure-open-ai-connectors.md

@@ -37,7 +37,7 @@ A documentation guidance and samples/examples will be created to guide on how to
 
 ## OpenAI SDK limitations
 
-The new OpenAI SDK introduce some limitations that need to be considered and pontentially can introduce breaking changes if not remediated by our internal implementation.
+The new OpenAI SDK introduce some limitations that need to be considered and potentially can introduce breaking changes if not remediated by our internal implementation.
 
 - #### ⚠️ No support for multiple results (Choices) per request.
 

docs/decisions/0049-agents-assistantsV2.md

@@ -154,9 +154,9 @@ A pending change has been authored that introduces `FunctionChoiceBehavior` as a
 
 #### Assistant Invocation Options
 
-When invoking an `OpenAIAssistantAgent` directly (no-chat), definition that only apply to a discrete run may be specified.  These definition are defined as `OpenAIAssistantInvocationOptions` and ovetake precedence over any corresponding assistant or thread definition.
+When invoking an `OpenAIAssistantAgent` directly (no-chat), definition that only apply to a discrete run may be specified.  These definition are defined as `OpenAIAssistantInvocationOptions` and overtake precedence over any corresponding assistant or thread definition.
 
-> Note: These definition are also impacted by the `ToolCallBehavior` / `FunctionChoiceBehavior` quadary.
+> Note: These definition are also impacted by the `ToolCallBehavior` / `FunctionChoiceBehavior` quandary.
 
 <p align="center">
 <kbd><img src="diagrams/assistant-invocationsettings.png" style="width: 370pt;"></kbd>

docs/decisions/0050-updated-vector-store-design.md

@@ -113,7 +113,7 @@ classDiagram
         class IVectorRecordStore~TModel~{
             <<interface>>
             +Upsert(TModel record) string
-            +UpserBatch(TModel record) string
+            +UpsertBatch(TModel record) string
             +Get(string key) TModel
             +GetBatch(string[] keys) TModel[]
             +Delete(string key)
@@ -619,7 +619,7 @@ Option 1 is problematic on its own, since we have to allow consumers to create c
 a single interface like this, it will require them to implement many methods that they do not want to change. Options 4 & 5, gives us more flexibility while
 still preserving the ease of use of an aggregated interface as described in Option 1.
 
-Option 2 doesn't give us the flexbility we need for break glass scenarios, since it only allows certain types of collections to be created. It also means
+Option 2 doesn't give us the flexibility we need for break glass scenarios, since it only allows certain types of collections to be created. It also means
 that each time a new collection type is required it introduces a breaking change, so it is not a viable option.
 
 Since collection create and configuration and the possible options vary considerable across different database types, we will need to support an easy
@@ -964,14 +964,14 @@ builder.Services.AddTransient<IFunctionInvocationFilter, CacheSetFunctionFilter>
 ### Collection Creation
 
 7. Release Collection Creation public interface.
-8. Create cross db collection creation config that supports common functionality, and per daatabase implementation that supports this configuration.
+8. Create cross db collection creation config that supports common functionality, and per database implementation that supports this configuration.
 9. Add support for registering collection creation with SK container to allow automatic dependency injection.
 
 ### First Party Memory Features and well known model support
 
 10. Add model and mappers for legacy SK MemoryStore interface, so that consumers using this has an upgrade path to the new memory storage stack.
 11. Add model and mappers for popular loader systems, like Kernel Memory or LlamaIndex.
-11. Explore adding first party implementations for common scenarios, e.g. semantic caching. Specfics TBD.
+11. Explore adding first party implementations for common scenarios, e.g. semantic caching. Specifics TBD.
 
 ### Cross Cutting Requirements
 
@@ -983,7 +983,7 @@ Need the following for all features:
 - Common Exception Handling
 - Samples, including:
   - Usage scenario for collection and record management using custom model and configured collection creation.
-  - A simple consumption example like semantic caching, specfics TBD.
+  - A simple consumption example like semantic caching, specifics TBD.
   - Adding your own collection creation implementation.
   - Adding your own custom model mapper.
 - Documentation, including:

docs/decisions/0058-vector-search-design.md

@@ -247,7 +247,7 @@ class AzureAISearchVectorStoreRecordCollection<TRecord> : IVectorSearch<TRecord>
 One of the main requirements is to allow future extensibility with additional query types.
 One way to achieve this is to use an abstract base class that can auto implement new methods
 that throw with NotSupported unless overridden by each implementation. This behavior would
-be similar to Option 1. With Option 1 though, the same bahvior is achieved via extension methods.
+be similar to Option 1. With Option 1 though, the same behavior is achieved via extension methods.
 The set of methods end up being the same with Option 1 and Option 3, except that Option 1 also has
 a Search method that takes `VectorSearchQuery` as input.
 

docs/decisions/0061-function-call-behavior.md

@@ -242,8 +242,7 @@ More details can be found here: [Serialize polymorphic types](https://learn.micr
 To support custom function choice behaviors, the custom types should be registered for polymorphic deserialization. 
 Clearly, the approach using the JsonDerivedType attribute is not viable, as users cannot annotate `FunctionChoiceBehavior` SK class. 
 However, they could register their custom type resolver that would register their custom type(s) if they had access to JsonSerializerOptions used by JsonSerializer during deserialization. 
-Unfortunately, SK does not expose those options publicly today. Even if it had, there are YAML prompts that are deserialized by the YamlDotNet library that would require same custom types s
-upplied via YAML specific deserializer extensibility mechanisms - YamlTypeConverter. 
+Unfortunately, SK does not expose those options publicly today. Even if it had, there are YAML prompts that are deserialized by the YamlDotNet library that would require same custom types supplied via YAML specific deserializer extensibility mechanisms - YamlTypeConverter. 
 This would mean that if a user wants the same custom function calling choice to be used in both YAML and JSON prompts, they would have to register the same custom type twice - for JSON 
 via a custom type resolver and for YAML via a custom YamlTypeConverter. That would also require a mechanism of supplying custom resolvers/converters to all SK `CreateFunctionFrom*Prompt` extension methods.
 
@@ -378,4 +377,4 @@ There were a few decisions taken during the ADR review:
 - Option 1.1 was chosen as the preferred option for the new function call behavior model.
 - It was decided to postpone the implementation of the inheritance mechanism that allows a service to inherit the parent function choice behavior configuration.
 - It was decided that the Breaking Glass support is out of scope for now, but it may be included later if necessary.
-- Option 2.5, which presumes supplying function call choices and function invocation configurations via prompt execution settings, was preferred over the other options due to its simplicity, absence of breaking changes, and familiar developer experience.
+- Option 2.5, which presumes supplying function call choices and function invocation configurations via prompt execution settings, was preferred over the other options due to its simplicity, absence of breaking changes, and familiar developer experience.