Even when JSON tableSchema paramert is used Emulator required to be running

[xperiandri]

Description

Even if I use JSON schema and specify tableSchema the provider tries to connect to Emulator.
And if Emulator is not running then provider crashes with connectivity exception.

Repro steps

Create JSON configuration.
Set up provider with it.
Build.

Expected behavior

Type provider successfully creates types using JSON schems.

Actual behavior

Type provider tries to connect to Storage Emulator.

Related information

• Windows 10 Pro x64 ENG 1803
• NuGet package version 2.0.0
• .NET Core 2.2

[xperiandri]

Error	FS3033	The type provider 'ProviderImplementation.AzureTypeProvider' reported an error: An error occurred during initial type generation for tables: Microsoft.WindowsAzure.Storage.StorageException: An error occurred while sending the request. ---> System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:10002
   at System.Net.Sockets.Socket.InternalEndConnect(IAsyncResult asyncResult)
   at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
   at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)
   --- End of inner exception stack trace ---
   at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
   at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)
   --- End of inner exception stack trace ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at Microsoft.WindowsAzure.Storage.Core.Executor.Executor.<ExecuteAsyncInternal>d__4`1.MoveNext()
   --- End of inner exception stack trace ---
   at FSharp.Azure.StorageTypeProvider.Table.TableMemberFactory.|BlobOnlyAccount|FullAccount|[a,b](FSharpResult`2 _arg1)
   at FSharp.Azure.StorageTypeProvider.Table.TableMemberFactory.getTableStorageMembers@23-1.Invoke(FSharpResult`2 _arg1)
   at Microsoft.FSharp.Control.AsyncPrimitives.CallThenInvokeNoHijackCheck[a,b](AsyncActivation`1 ctxt, FSharpFunc`2 userCode, b result1)
   at Async.map@15-3.Invoke(AsyncActivation`1 ctxt)
   at Microsoft.FSharp.Control.Trampoline.Execute(FSharpFunc`2 firstAction)
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.FSharp.Control.AsyncResult`1.Commit()
   at Microsoft.FSharp.Control.AsyncPrimitives.RunSynchronouslyInCurrentThread[a](CancellationToken cancellationToken, FSharpAsync`1 computation)
   at Microsoft.FSharp.Control.AsyncPrimitives.RunSynchronously[T](CancellationToken cancellationToken, FSharpAsync`1 computation, FSharpOption`1 timeout)
   at Microsoft.FSharp.Control.FSharpAsync.RunSynchronously[T](FSharpAsync`1 computation, FSharpOption`1 timeout, FSharpOption`1 cancellationToken)
   at FSharp.Azure.StorageTypeProvider.Table.TableMemberFactory.getTableStorageMembers(FSharpOption`1 optionalStaticSchema, Int32 schemaInferenceRowCount, Boolean humanize, String connectionString, ProvidedTypeDefinition domainType)
   at <StartupCode$FSharp-Azure-StorageTypeProvider>.$AzureTypeProvider.clo@83-208.Invoke(Tuple`2 tupledArg)
   at <StartupCode$FSharp-Azure-StorageTypeProvider>.$AzureTypeProvider.clo@85-204.Invoke(Tuple`2 tupledArg)

[isaacabraham]

@xperiandri thanks for raising this. Funnily enough, I was actually thinking about this yesterday and came up with the exact same thought - we shouldn't connect if a schema is provided.

[hoetz]

I want this too :)
Guess it might have to be a change around somewhere in here?

AzureStorageTypeProvider/src/FSharp.Azure.StorageTypeProvider/Table/TableMemberFactory.fs

Line 23 in 2be7cc0

match! (getTableClient connectionString).GetTableReference("1").ExistsAsync() |> Async.AwaitTask |> Async.toAsyncResult with

[isaacabraham]

I'm not sure. I had a quick look at the code the other day - there's a guard in the top of the TP which should prevent that test happening:

AzureStorageTypeProvider/src/FSharp.Azure.StorageTypeProvider/AzureTypeProvider.fs

Lines 63 to 66 in 2be7cc0

	let connectionStringValidation =
	match staticBlobSchema, staticTableSchema with
	| Some _, _ | _, Some _ -> None
	| _ -> Some (validateConnectionString connectionString)

i.e. if you supply either blob or table schemas, we shouldn't be connecting at all. So the connection must be happening elsewhere.

[hoetz]

If connectionStringValidation evaluates to None, wouldn't getTableStorageMembers still be called here?

AzureStorageTypeProvider/src/FSharp.Azure.StorageTypeProvider/AzureTypeProvider.fs

Line 83 in 2be7cc0

(TableMemberFactory.getTableStorageMembers tableSchema schemaInferenceRowCount humanizeColumns, "tables")

Might try to debug this later :)

[isaacabraham]

@hoetz mmmm, good spot. Looking into that function, it looks like the behaviour here was inadvertently changed after I added support for blob-only accounts. I've created an experimental-fix-static-schema branch which should fix this - can you try building against that? I've not tested it at all - it compiles and builds though ;-)

[hoetz]

Tested it with the current dll from the nuget package and with the one built from the branch and it works! My test project now builds when the emulator is shut down. When falling back to the nuget version it fails again. 🥇
All integration tests pass as well - did a full build.

[isaacabraham]

@hoetz this is now released on nuget.

[hoetz]

Great, I think I was the first to download it last night :)